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.
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.
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.
To learn more about microservices:
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.
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.
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.