Microxchg 2016: A pattern language for microservices

A couple of weeks ago, I spoke at the MicroXchg conference in Berlin. It is a small, two track conference that is just about microservices. Lots of great topics. In particular, it was nice to see that the discussion has moved beyond the basics of what is a microservice? Quite a few speakers shared their practical experiences with using to microservices. Notable speakers included James Lewis, Suzanne Kaiser,  and Praveena Fernandes.

I gave a talk on a pattern language for microservices. Here are the slides.

Here is the video.

I also took part in a panel.

Berlin has some good restaurants. I had some great Turkish food at Hassir Mitte.

Learn more

To learn more about microservices:


Posted in microservices, Uncategorized | Tagged , , , , | 1 Comment

Microservice chassis pattern

Build your microservices using a microservice chassis, which is a framework that handles cross-cutting concerns

When you build a microservice you must put in place the mechanisms to handle cross-cutting concerns such as logging, externalized configuration, health checks, metrics, service discovery, and circuit breakers. You cannot afford to spend a significant amount of time doing this for each service. Therefore, you should build your microservices using a microservice chassis, which is a framework that handles these cross-cutting concerns.

For a full description of this pattern see Microservice chassis pattern.

Posted in microservices, Uncategorized | Tagged , | Leave a comment

Microservices – more than just infrastructure


Matt Miller of Sequoia recently published a map of the microservices ecosystem.

The ecosystem map is very focussed on infrastructure. It lists many of the usual suspects including Docker, Kafka, Cloud Foundry, Azure, and Chef. It includes some developer frameworks such as Hystrix but unfortunately, the focus on infrastructure means there are some surprising omissions.

Microservices need a chassis

James Watters from Pivotal, for instance, points out that Spring Boot and Spring Cloud are nowhere to be seen:

That is a shame because if you are building microservices you need a microservice chassis, such as Spring Cloud + Spring Boot. A microservice chassis is a framework that enables you…

View original post 262 more words

Posted in Uncategorized | Leave a comment

API Gateway pattern

Have a service that acts as the sole entry point into a microservices-based application

Consider a mobile shopping application.  The product information that it needs to show to the user includes the description, price, reviews, recommendations and shipping information. The ownership of that data is spread among a number of microservices. In theory, the application could access each microservice separately. But in practice, it makes more sense for the mobile application to retrieve the needed information by making a single request to a service known as an API Gateway, which aggregates data from multiple services.

For a full description of this pattern see the API Gateway Pattern.

Posted in microservices, Uncategorized | Tagged , | Leave a comment

Microservices architecture pattern

Functionally decompose an enterprise server-side application into collection of services that can be developed, deployed and scaled independently

A successful application typically grows in complexity as developers implement more and more features. At some point the application becomes so complex that modularity breaks down and it degenerates into an unmaintainable ball of mud. Agile development and deployment becomes impossible. The development team can no longer keep up with the needs of the business.

The Microservices Architecture pattern functionally decomposes the application into a collection of services that are easier to understand. Each service can be developed, deployed and scaled independently. The velocity of the development team increases dramatically.

For a full description of this pattern see the Microservices Architecture Pattern.

Posted in microservices, Uncategorized | Tagged , , | Leave a comment

Does each microservice really need its own database?

The short answer is yes. However, before you start hyperventilating about the cost of all those extra Oracle licenses, lets first explore why it is essential to do this and then discuss what is meant by the term ‘database’.

The main benefit of the microservice architecture is that it dramatically improves agility and velocity. That’s because when you  correctly decompose a system into microservices, you can develop and deploy each microservice independently and in parallel with the other services. In order to be able to independently develop microservices , they must be loosely coupled. Each microservice’s persistent data must be private to that service and only accessible via it’s API . If two or more microservices were to share persistent data then you need to carefully coordinate changes to the data’s schema, which would slow down development.

There are a few different ways to keep a service’s persistent data private. You do not need to provision a database server for each service. For example,  if you are using a relational database then the options are:

  • Private-tables-per-service – each service owns a set of tables that must only be accessed by that service
  • Schema-per-service – each service has a database schema that’s private to that service
  • Database-server-per-service – each service has it’s own database server.

Private-tables-per-service and schema-per-service have the lowest overhead.  Using a schema per service is appealing since it makes ownership clearer. For some applications, it might make sense for database intensive services to have their own database server.

It is a good idea to create barriers that enforce this modularity. You could, for example, assign a different database user id to each service and use a database access control mechanism such as grants. Without some kind of barrier to enforce encapsulation, developers will always be tempted to bypass a service’s API and access it’s data directly.

It might also make sense to have a polyglot persistence architecture. For each service you choose the type of database that is best suited to that service’s requirements. For example, a service that does text searches could use ElasticSearch. A service that manipulates a social graph could use Neo4j. It might not make sense to use a relational database for every service.

There are some downsides to keeping a service’s persistent data private. Most notably, it can be challenging to implement business transactions that update data owned by multiple services. Rather than using distributed transaction, you typically must use an eventually consistent, event-driven approach to maintain database consistency.

Another problem, is that it is difficult to implement some queries because you can’t do database joins across the data owned by multiple services. Sometimes, you can join the data within a service. In other situations, you will need to use Command Query Responsibility Segregation (CQRS) and maintain denormalizes views.

Another challenge is that  services sometimes need to share data. For example, let’s imagine that several services need access to user profile data. One option is to encapsulate the user profile data with a service, that’s then called by other services. Another option is to use an event-driven mechanism to replicate data to each service that needs it.

In summary,  it is important that each service’s persistent data is private. There are, however,  a few different ways to accomplish this such as a schema-per-service. Some applications benefit from a polyglot persistence architecture that uses a mixture of database types.  A downside of not sharing databases is that maintaining data consistency and implementing queries is more challenging.

Posted in architecture, microservices | Tagged , , | 12 Comments

Monstrous monoliths – how bad can it get?

I recently posted a survey on twitter asking folks to describe their monolithic application:

So far I’ve had around 12 responses. As of 5/13/15, here are the “winning” answers to each question:

How many lines of code? 2.2M
How many jar files? 418
How long to startup? 12 minutes
How large is the WAR? 373 MB

The ages of the applications ranged from 2 to 13 years.

Do you have some winning metrics about your monstrous monolith you would like to share? If so, fill in this form.

Posted in microservices | Tagged | 1 Comment