My new O’Reilly training video: Event-Driven Microservices

I am super excited about my new training video that has just been published by O’Reilly: Event-Driven Microservices – a Pattern Language for Deployment, Communication, and Refactoring. The 4 hour 46 minute video presents a balanced view of the benefits and drawbacks of microservices. It outlines the motivations driving the adoption of the microservice architecture; compares and contrasts it to monolithic architecture; describes solutions to key problems such as inter-service communication and distributed data management including event sourcing and CQRS; and presents strategies for refactoring a monolithic application into a set of microservices.

The video complements my in-person training classes, which include a 2 day, on site microservices workshop that is a great way for a team to get up to speed with microservices. As one recent customer said:

This class was fantastic. Chris communicates complex concepts clearly. His sense of humor and calm nature are real strengths and he really helped my team build confidence. It was refreshing to learn about microservices architecture from someone who not only understood the decisions & tradeoffs we will need to manage but has the ability and experience to present pros and cons in a balanced way.
Dave King, CTO – NAV

Another training option is the  one day microservices class that I am teaching in Oakland, CA on April 28th. There are still spots available so take a look.

Posted in microservices | Tagged , | Leave a comment

Thoughts on “if you can’t build a well-structured monolith, what makes you think microservices is the answer?”

A couple of weeks ago at the DevNexus conference Simon Brown gave a keynote (slides) titled the “Modular Monolith”.  It was an interesting presentation and he made a number of good points. His final slide asked this excellent question:

If you can’t build a well-structured monolith, what makes you think microservices is the answer?

He had made a similar point on Twitter:

As had other tweets:

 

 

I don’t disagree with the sentiment of Simon’s question. But I think it misses a critical point.

Most teams know how to build a modular system. They want to build a modular system. Most teams usually do. The challenge is maintaining the modularity. A large and/or complex application will often degenerate into a big ball of mud.

The challenge is maintaining modularity

There are several factors that make it difficult to maintain modularity:

  • Current programming languages lack genuinely useful modularity mechanisms. Java visibility rules are insufficient. Perhaps Java 9 modules will finally solve this problem.
  • Monoliths often become too complex for a developer understand. This increases the chance that changes will violate implicit modular boundaries causing the design to degrade.
  • Time pressure. There are no depths to which a developer will not sink (especially under pressure from management) in order to meet a deadline. Who cares about modularity when you need to ship software?!

Microservices can help with modularity

Microservices are certainly not a silver bullet. But one benefit they offer is that your application is functionality decomposed into smaller (not necessarily tiny) services. Each service is much easier to understand. In theory, it is easier to preserve its architecture and modularity.

More importantly, the service API is an impermeable barrier that encapsulates the service implementation. It takes real effort and determination to breach that barrier.  A developer is less likely to make a quick hack to solve a problem the night before a deadline. As a result, it is likely that it will be easier to maintain the modularity of the system.

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

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

Eventuate.IO

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