If you’re an application architect it’s unlikely that you have missed the emergence of the latest buzzword in our armoury : Microservices. And, if you missed it before you’ve found it now.
Whether or not you are familiar with microservices, I want to introduce you to what I think is an important clarification of microservice architecture: the distinction between simpler “inner architecture” and more complex “outer architecture”.
First, some level-setting… Microservice architectures promise to deliver flexibility and scalability to the development and deployment of service-based applications. But how is that promise delivered? In short, by adopting an architecture that allows individual services to be built and deployed independently and dynamically; an architecture that embraces DevOps practices.
Need to release an update to your customer profile service? Well, it’s “micro”, so it’s simple to grok and its developers can focus on just that functionality. And when it’s ready, you can just test and deploy that service – no need to bundle it up with the rest of your application, no waiting for a release window. Is the same service creating bottlenecks when demand spikes in the evenings? Scale out by deploying a few more instances of just that (micro)service.
It all sounds great, right? These are the aspects of microservice architecture that much of the discussion and excitement has centered around for the 12 months or so. These are the topics that have driven so much enthusiasm.
Microservices are simpler, developers get more productive and systems can be scaled quickly and precisely, rather than in large monolithic globs. And I haven’t even mentioned the potential for polyglot coding and data persistence. In my recently published research “Assessing Microservice Architecture for Scalable Application Delivery” I call this the “inner architecture”, it is the implementation architecture of the microservices themselves.
But it’s not the full story. To come close to the apparent nirvana of the (oversimplified) scenario above you have some work to do: you have a tremendous responsibility to stick to your interface contracts, and you have to manage the development, deployment and operational complexity of a distributed system.
The complexity you removed from your services to simplify them has not gone away and it brings new challenges, and amplifies old ones. You will meet this “moved” complexity when you test and deploy your microservices, when your microservices need to communicate, when you need to understand the health of your environment, or when you need to diagnose an issue this distributed, and potentially polyglot.
That complexity has moved and, I would argue, increased. It now lives in what I call the ”outer architecture”. The Outer Architecture delivers the platform capabilities you need to help all those simple little microservices (and their DevOps teams) work together to make good on the promises of flexible and scalable development and deployment. It is coping with this complexity that makes SDLC discipline and automation an essential element of delivering microservice architecture.
The diagram below is a simplified version on one published in my research, which shows how the inner and outer architecture relate. Microservices A through D are different services (possibly with different inner architectures) and each has one or many instances deployed and executing.
Inner and Outer Architecture
As you can see, the visceral elements of your architecture, the guts, sit outside your service implementations and the architecture inside each microservice encapsulates its logic and data persistence. If you start evaluating or adopting microservices you need to think about these outer architecture capabilities along with all the the fun inner architecture that everyone is so excited about.
Right now, my view is that the best starting point for the outer architecture is an aPaaS (application platform as a service) platform or framework. But, vendors will not miss the opportunity to “microservices-wash” their tools and platforms to get your attention. Some will be more suited to microservices than others, so I implore you to understand the capabilities you need using our research or by doing your own, rather than waiting for a vendor to tell you what they think you need (and should pay for.)
While not a panacea, I can see the potential for microservices to change the way we build, maintain and operate applications. When delivered with discipline they help applications become more evolvable, more portable, and more adaptive, particularly as organisations look to migrate application workloads to private or public cloud platforms. I encourage you to learn more about microservices from Gartner and the many other resources on the topic.
Just remember that delivering a successful microservice architecture takes guts.
The post Microservices : Building Services with the Guts on the Outside appeared first on Gary Olliffe.