The benefits of moving to new modern application architectures like Micro Services and runtimes like Docker are well accepted. Most organisations that see IT as a core part of their business are either adopting these new application and runtime architectures or looking to move towards them over the coming years.
But where does this leave the current applications – the so called Monoliths? These three tier applications with presentation, middleware and data layers – written in the likes of Java or .Net, with SQL backends are numerous and what currently constitute the largest part of the estate for many organisations, especially those that are refered to as “Enterprise Organisations”.
The characteristics of an “Enterprise” are generally large disparate IT environments with numerous applications built in house, added through acquisition, and have generally been around for some time. These applications were built using technologies that were best of breed at the time they were designed – but as technology has evolved rapidly in recent years this has now left many large IT dependent organisations with the majority of their core systems that appear to be outdated. These same organisations are also the ones that have traditionally struggled to move in an efficient agile manner.
How our are these organisations meant to respond? Will they be able to move everything to Micro Services and containers in a timely manner? Is there a suggested approach to achieve this? And what should be done with the existing ‘Monolithic’ applications that currently run the business?
How?
For many organisations looking to move to much more moderns application environments the starting point should be to move their current applications and infrastructure to a utility cloud based model with as few changes as possible. This involves moving existing applications and environments with without re-architecting them.
Amazon Web Services (AWS) refer to as the “Forklift” approach – or more generally know as ‘lift and shift’. In order to migrate large numbers of existing application components and infrastructure this is seen as the quickest and most efficient approach. The objective is to move the existing applications and infrastructure with as few changes as possible to a more current architecture. Obviously changes to the network, storage, compute, security and other layers are necessitated by moving from an on Premise Data Centre to a Public or Private Cloud – but the overall three tier architecture of the application – Presentation Tier, Middleware and Backend Data Services should remain in place.
This also allows organisations to become familiar and enabled with more modern operations runtimes – monitoring, autoscaling, provisioning and deploying applications in an automated fashion to name a few. Monolithic applications are still able to utilise these more contemporary paradigms – they may not be as efficient at doing so as containerised applications but there are material benefits to infrastructure, licensing and operations costs that justify the move. Not to mention allowing operations teams to become familiar with new tooling and the business to benefit from reduced operational costs and lowering the risk by changing to many things at once.
Existing applications and backend services should in most cases be moved before considering re-architecting the applications.
What?
What applications are a good candidate to move to Micro Services is a question that is not always an easy one to answer. Should most Enterprises be moving some of their applications to Micro Services? The answer is almost certainly yes. Should they be looking to move all applications to Micro Services? The answer is probably no. So which are the ones that need to be moved?
The applications that are likely to benefit most are ones that need to be innovated the most quickly – the ones that are likely to see the most change and can benefit from the evolution of new technology for web, mobile and front end services. Organisations also need to consider the cost benefit for moving for each application. Components of a vehicle may have evolved to use new materials – from steel, aluminium, composite plastics to carbon fibre. But are cars all made of carbon fibre? No. Where existing components are fit for purpose there may be no need to consider moving them – you may be able to improve the presentation, user interaction and over all performance of a car or application by moving to new materials or technologies – whilst retaining the chassis or backend services with relatively few change.
Why?
There is a lot of hype about containerised applications and Micro Services – and for good reasons. The portability of applications, the packaging, efficiency and scaling to name but a few are almost without question. But whilst in the midst of such as monumental shift in how applications are designed and run – it is often easy to get carried away with how far things should be taken.
Much of the movement that sits around more modern application architecture is driven by a desire to innovate and a belief that things can be done better – the DevOps movement characterises much of this. These are admiral and lofty goals that are revolutionising the way applications are created and maintained. However, whilst in the midst of such tectonic changes its is easy to think that everything should be based on these new models.
The why is a very important question – the ability to innovate, scale and reduce operational costs in many instances will justify this. However, monolithic applications that are fundamentally fit for their current purpose, have no apparent functional requirements to be re-written and aren’t incurring infrastructure, licensing or operational costs that justify a move should be candidates in remain in place.
When?
Whether moving to a private cloud capability based on OpenStack or Cloud Foundary – or to a public cloud like AWS, Azure or Google – the most efficient approach is to move applications without re-architecting them, then during an optimisation phase re-engineer components.
The when articulated here is prodominently focused on “Enterprise” organisations that run their monolithic applications in a traditional on premise model – which usually involves running development and test environments 24/7 with no concept of provisioning infrastructure on demand, nor autoscaling production systems to handle peak load but simply running production environments to handle peak workloads whilst in fact for the majority of the time they are hugely over provisioned.
During the migration phase to a cloud model the foundations should be laid using automation frameworks that allow the infrastructure to utilise the technical and commercial benefits of running in the cloud.
Automation is the foundation of this – it is simply not possible to provision infrastructure and applications on demand, decommission under utilised servers, autoscale or to provision development and test infrastructure just for the life cycle of a test, without a comprehensive automation capability. All of these are capabilities that are essential when managing container based applications – and a phased approach to adopting this techniques before re-architecting applications will allow for smoother adoption.
Combining the ability to provision / run all non production infrastructure on demand – as well as auto scale components of a production system, will result in a significant reduction in the infrastructure footprint.
Summary
There is unquestionable huge benefits for Micro Services applications architectures running in containers. This is most certainly something that organisation that are increasingly seeing themselves as technology companies, whether in finance, retail, telecoms or any other industry should be looking at if they have not already started down this path.
The critical questions however are how best to lay the foundatoins / create a platform for adopting this new architecture, deciding which applications are the best candidates to move first whilst at the same time creating operational efficiencies with the largest part of the current infrastructure – the Monoliths. There is a huge amount of materials espousing the benefits of Containerised Micro Services applications but less discussed is the path to get there. This material has not focused on the challenges that exist around developing and managing Micro Services which are also not insignificant – moving to stateless, loosely couple architectures also presents challenges outside the operational ones covered here.
Our recommendation is to have a considered pragmatic approach concentrating on which applications will gain the most by being re-architected whilst at the same time looking to obtain operational efficiencies in the ones that are currently not deemed ready to do so.