As you round out 2015 reflecting on all your IT achievements throughout the year, you’re probably starting to look ahead and think about upcoming priorities for 2016 to enhance your digital experiences or build completely new services. If you’re feeling particularly motivated, you may be contemplating your approach and giving consideration to which new technologies you should be deploying and methodologies you should be leveraging to help you deliver these projects more effectively.
No doubt you will have heard the term “microservices”. If you’re wondering what all the hullaballoo is about and whether this is something you need to be considering, read on.
Microservices have become a necessity for digital-forward companies (think Netflix and Uber) and will be a game-changer for application development and infrastructure service delivery going forward. So we thought we’d share what they are, why they matter and how they will become increasingly relevant to Infrastructure and Systems Specialists alike.
What are microservices?
A microservices architecture is service-oriented and composed of loosely coupled elements that have bounded contexts. Applications are developed and deployed as sets of microservices, which put simply are small, autonomous services that work together.
Small and focussed on doing one thing well
This is a reaction to codebases that grow large, making it really hard to track where changes should be made and what the impact of the changes will be on the rest of the system. Developers strive for cohesion, which is the drive to have related code grouped together. With microservices, the service boundaries become focussed on business boundaries, which makes it more obvious where code lives for a given piece of functionality. Some rules of thumb as to how small a microservice should be, are that it should be able to be re-written in two weeks and should be able to be managed by a single small team.
A microservice is a separate entity and communication between all these services are via network calls, to enforce separation between them. These services need to be able to change independently of each other, and be deployed by themselves without requiring consumers of the service to change. The services expose an application programming interface (API), and collaborating services communicate via those APIs.
Why would you want microservices?
In this new digital world customers are interacting with a range of different devices including desktop, mobile, wearables, and increasingly the internet of things. Customers are also demanding always-on services with the latest innovation, making it clear that the historical approach to systems architecture is no longer working. The times of building a single integrated application containing the majority of features and functions, simply can’t achieve the agility, flexibility and scalability demanded of today’s applications and user behaviours.
In monolithic application architecture the application is written as a single, unified code base, which means that any changes require rebuilding and testing the entire application. This was fine when companies deployed updates only a few times a year, but in today’s fast-paced environment, an app that pushes updates only a few times a year cannot be competitive.
Microservices are therefore attractive because they deliver on the attributes that are desirable of cloud native application architectures. These are the essence of what have made market disruptors like Uber, Netflix and Airbnb so successful.
Key benefits are:
- Speed of innovation - release features faster and more often for competitive advantage.
- Always-available services - limit the scope of any failure to only the function of the microservices and avoid it cascading: automatically recover from failures by redeploying a failed component.
- Web scale - containers are a popular way of incrementally scaling services and microservices meaning we only need to scale the parts of the systems that require more.
- Mobile-centric user experiences - digitisation means that the presentation layer for our services can be anything from Web, to native application, mobile web, tablet app, or wearable device. With microservices we can compose these presentations each separately through API interfaces to the backend application.
The following diagrams help visualise one of the specific benefits of microservices, namely the ability to scale services independently.
Source: Martin Fowler
So, apart from wanting to emulate the market disruptors, why would New Zealand enterprises find a microservices approach relevant?
Coping with Disruption
If a new entrant were to enter your market via a traditional route or from an adjacent industry, how quickly would you be able to pivot your service offerings to react to market trends or nullify their competitive advantage?
An excellent slide doing the rounds has a call to arms, crying “The Digital Disruption Has Already Happened” and then lists examples showing how previous barriers to entry have dissolved:
- The world’s largest taxi companies owns no taxis (Uber)
- Largest accommodation provider owns no real estate (Airbnb)
- World’s most valuable retailer has no inventory (Alibaba)
- Most popular media owner creates no content (Facebook)
- And more…
As a counter point to this, arguably a valid business strategy is to exploit a market for as long as it will bear it before reacting (possibly less noble, but not without precedent – think entertainment content providers). However, the disruption will come at some point, almost with certainty. So will you be ready to react to it?
Change is too hard to effect with the current approach
If your present applications and solution development approach is too rigid, you have to change how you approach it. The fundamental design of the system has to make it easy to make changes. This is where the microservices architectural approach comes in.
Infrastructure automation, automated testing and continuous delivery techniques can all help improve speed and agility, but there are limits to what can be achieved unless the fundamental design of the system makes it easy to make changes. This is why it is important to have those foundation elements in place AND change the systems development approach.
Insight from Infrastructure Architects in this world of System Architects
There is more nuance to the term resilience
In an infrastructure domain, resilience will mean having duplication of components to avoid any single point of failure, and essentially the infrastructure is a passive participant upon which the applications rely. To a system architect however, resilience can be far more granularly effected. With microservices communicating via calls to one another, resilience can be achieved through having load balancers between tiers and avoiding holding any state in the components, so failures have less impact. In addition, by isolating failures through concepts like circuit breakers or bulkheads, the impact of a failure does not cascade to other parts of the system.
It's important not to chase the tail of technology
The pace of technology advancement and innovation appears to all of us in the middle of it to be accelerating (bring on the singularity!). This makes it ever more important to be able to leverage new technology, in a controlled and safe manner and as it emerges.
As an aside, hardware innovation alone has arguably diminishing returns (especially as the hardware we use becomes more commoditised). And leveraging hardware innovation needs to be limited to investment cycles – we can’t replace assets until their original value has been extracted. This, by the way, is one element of why cloud becomes so attractive, because we can (within limits) pay for it, turn it on and then turn it off and stop paying for it once something better comes along (within the limits of being able to migrate services between offerings, as I was saying).
And so coming back to application development innovation, this is also what makes the microservices approach so appealing as well. The bounds of a service are smaller, so there is greater ability and opportunity to try something new (e.g. Docker, Flocker, Rocker!) and see if it will provide benefits that should be realised more widely through the system. If we really can rebuild a microservice in two weeks, then the impact of shifting to leverage new technology is also greatly diminished.
Principles of microservices
The way to ensure you extract the value from microservices that are promised, is to adhere to these principles:
- Model around business concepts – keep looking for the seams around which service boundaries can be formed
- Adopt a culture of automation – everywhere and use this as the foundation
- Hide internal implementation details – to ensure that we can keep the microservices autonomous, not requiring our consumers to change when we make changes
- Decentralise all the things – to avoid tight coupling between services
- Independently deployable – so we can get features out faster without slowing down the rest of the system’s development
- Isolate failure – to avoid cascading failures
- Highly observable – with more moving pieces, it is more important to understand how they are all performing
How can we build on what we have already achieved?
On the surface of it you might be worried that this new world requires us to discard what has come before and re-build (again). However, mercifully, this is not the case. This step, of moving to a microservices framework, is another along the journey path to cloud (native applications).
The Software Defined Data Centre (SDDC) delivers on centralised control through policy enforcement and automated configuration of virtualised components for all parts of the infrastructure. As we have seen these are foundational elements for improving agility, availability and scalability. They are also the same foundational elements required for underpinning a move to microservices on-premises. Off-premises approaches include Platform as a Service offerings like Heroku, Pivotal cf and AWS, where these elements are provided for you.
Whether you decide to deliver a microservices capability on- or off-premises:
- APIs are the key to automation of the end-to-end workflow.
- It is important to break down the workflow into the smallest possible units (aka pipelines). And each pipeline creates an artifact.
- Automate as much as you possibly can.
- Add/enhance the quality of the logs (failures, success info).
- Provide visibility and action items where intervention is required.
Automation is so critical and it goes hand in hand with Orchestration. In a microservices approach there will not be a single tool in isolation, which will address all your needs across the SDLC. You will most likely live in a world where you will have 6, 8, 10 or even more disparate tools across continuous integration and build, issue and project tracking, version control and automated testing. This makes orchestration across tools a necessity.
As part of the VMware SDDC approach, vRealize Code Stream provides an integration and orchestration framework for pipeline development. Internally this framework is based on Jfrog Artifactory and vRealize Orchestrator. Out of the box a variety of plug-ins for tools across the SDLC are supported. This approach of “integrate and extend” allows you to leverage your existing investments and developers can continue to use their favorite tools.
This makes the SDDC the perfect platform on which to establish the infrastructure provisioning automation, containerisation, automated testing and continuous delivery on-premises. And this is precisely what is needed to underpin the transition into these loosely coupled and highly cohesive microservices that will enable you to be the new market disruptors, rather than being the Kodak film disruptees.
Source: Newman, Sam (2015-02-02). Building Microservices. O'Reilly Media