Migrating to Cloud-Native Application Architectures, Matt Stine.
In the last few years, it can be very easy to believe marketing departments simply aren’t paid unless they use the word "Cloud" as often as possible. Its usage has become so ubiquitous that is has inevitably become ambiguous so one very astute thing author Matt Stine does is outline what he means by "Cloud" (in particular cloud architectures) in the opening pages of this book. Essentially, cloud architectures can be summarised by the three S’s.
- Speed: ability to provision and release resources (computing, networking and storage) with ease thereby achieving faster project development time
- Safety: making software architectures more resilient (fault tolerance, fault isolation etc)
- Scalability: One the many non-functional characteristics that has become even more important with proliferation of mobile computing. More mobile devices mean more application usage mean more back ends APIs getting hit. Architectures must be able to respond to this demand otherwise applications fail.
Twelve Factor App
Throughout the book approaches and patterns for achieving cloud based architectures are introduced. Now, if you have worked on anything distributed which was well architected, you will definitely experience a little bit of deja vu. For example, the Twelve Factor App is a collection of patterns developed by engineers at Heroku containing twelve (you guessed it) principles to guide a good architecture fit for cloud. You are sure to have used codebase (make deployable units have their own code base), dependencies (use proper tooling for managing dependencies), config (externalise configuration), backing services (databases, caches etc should be consumed identically by all resources) before but patterns are supposed to be common solutions to common problems and good architecture is good architecture, so it is not unexpected some of the described approaches won’t always sound completely new.Microservices
How do Microservices help enable the 3 S’s?
- Speed: Deployment is much simpler and faster with independent code chunks.
- Security: Not too much here, but it is fairly intuitive that if you break something large into small chunks it is much easier to access control sensitive parts.
- Scale: Much easier to only have to scale the parts of an architecture you need to scale as opposed to having to scale the entire architecture - which is what happens in a Monolithic application.
Cloud Migration
For organisations to move to Cloud based architectures, several changes are needed:
- DevOps rather than Silos: this is to facilitate speed of delivery.
- Continuous Delivery: one way to be to sure the problems of long release cycles are guaranteed to be avoided
- Decentralise autonomy: yes, it is a nice idea to give everyone more power and influence. It will certainly speed things up. But, in my own view some things (core APIs, major technical architectural decisions) should only be handled by people of a certain technical background who are prepared to be fully accountable for them. Would you let every person working on the design of a bridge or in a heart transplant have the exact same say?
- Inverse conway manoeuvre: Software companies should do their architecture first and then re-align their organisations to fit that so that they avoid the anti-pattern of making architectures to resemble an existing organisational structure. This sounds nice in theory but it may not be so easy to achieve (possibly easier to do in very small companies that never have a strict organisational structure anyway).
Break up the Monolith
So if you have bought into the cloud based approach and since it’s unlikely your project is green field, you need to figure out how to break up the Monolith. Some ideas include:
- Bounded Contexts: This allows inconsistent definitions of concepts as long as they are consistent inside a well defined context which makes it much easier to decompose data models. For example, in the Security context a User may always refer to something that can be authenticated and has particular roles but in a Management context it would be something that has an image, an address and some application capabilities (checking out a shopping cart).
- Identifying bounded contexts in the monolith and making them micro services.
- Containerisation: Using something like Docker can provide many advantages to using VM's
- Writing new features as micro services
- Making the Monolith look like micro services by using anti-corruption layers
Spring cloud and Netflix
By the sounds of it Spring cloud's and the Netflix OSS project sound like an absolute must to checkout. Amongst other things, they help:
- Achieve dynamic configuration
- Implement sophisticated service discovery
- provide alternative to load balancing which involve client side more.
In addition, Netflix's Hystrix library (which provides some very useful metrices) employs some clever fault tolerance patterns:
- circuit breakers - if a system notices that another system is broken it stops calling it.
- bulkheads - failure is limited by strict partitioning
Any negatives?
So lots of positives about this book. Plenty of well explained information in a short number of pages. That is a major achievement. I have alluded to a few minor points above, but they are very minor. It would be very difficult to criticise this book in any substantial manner especially when it is free.
However, it is important for the reader to bear a few considerations.
- Business realities: Approaches such as Continuous Delivery just may not fit your business plan. Why would you want to provide a feature someone hasn’t paid for? (In fairness, the author does make this very point, but it really is worth re-iterating)
- Technical realities: One problem I have with many software approaches is that they assume that everyone is at a given skill level. In an ideal world the only people who work in software engineering would be very good engineers but the reality is there is always a very wide range of skill levels on any project. From super meticulous to complete spoofers. This means that some things that can sound very elegant in theory but a lot more difficult to achieve in practise. When considering moving to things like DevOps, there will definitely be benefits. But are organisations going to find it easier or harder to make engineers accountable? I would imagine there would be serious risks of it being latter if it is not properly thought through.
- Some concepts e.g. Client Side load balancing sound very interesting. But, they are only introduced rather than critically analysed. Much more research and thought would be required (for me anyway) before considering adopting.
