Deployment Automation and Microservices – More Questions than Answers

The automation of application deployment (Deployment Automation) is essential for any business aspiring to gain maximum value from IT. Deployment Automation (DA) allows an application to be transitioned to its respective environments without the need for manual intervention. DA is not about pure speed. A script that executes a copy command or even an person executing a copy command will get the same files from A to B across the same network in about the same time. DA is about increasing throughput, minimising failure, ensuring repeatability and providing traceability and audibility. Market leading tools such as Automic ARA allow you to parallelise deployments, provide role based access control (RBAC), configuration management, reporting and analytics, compliance and auditing functions, and even the ability to compare environments. As part of a DevOps strategy, such tools can transform an enterprises ability to make new offerings available to their customers.

This brings us nicely to Microservices, the latest topic everyone is talking about. The key concept behind them is to architect large, complex and long-lived applications as a set of cohesive services that evolve over time. Microservice architectures (MSAs) entice businesses by offering benefits of simplicity, flexibility, scalability, and increased productivity. This means that development and deployments can focus on a particular microservice instead upgrading of the entire application. This sounds like nirvana however whilst these services are indeed stripped down and simple the complexity that provides the cohesion and application context has to go somewhere.

It has moved and many would argue, increased. It now lives in what Gary Ollifee, a Research Director at Gartner, calls 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 above 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. As you can see, the visceral elements of this architecture, the guts, sit outside your service implementations and the architecture inside each microservice encapsulates its logic and data persistence. When starting to evaluate or adopt microservices you need to think about these outer architecture capabilities along with the “inner architecture” that everyone is so excited about. See the full Gartner article Microservices: Building Services with Guts on the Outside.

This sentiment is echoed by Sudhir Tonse, a Cloud Platform Manager at Netflix, as he understands that one rogue micro service can bring your whole site/application down and from an Operations perspective, the challenges of shifting to MicroServices should be understood and appreciated and that best practices should be leveraged and battle-tested OSS [Operations Support System] components should be used. See Microservices at Netflix for further information.

At ECS Digital we believe there is an additional outer layer of complexity that is prevalent in most MSAs, the container. Containers have been around since the early 2000’s but have really taken centre stage with the emergence of Docker. Many people are predicting containers will be as transformative for IT as was full machine virtualisation pioneered by VMWare nearly 16 years ago. Management of virtual machines (VMs) in the early years of rapid adoption was a challenge as tools to manage the creation, removal and cost management didn’t exist. VMs were being created with no cost associated and therefore rarely removed. This led to the VM sprawl. Fast forward to the present day and the combination of MSAs and containers. The number of disparate components of an application is multiplied with the move to Microservices and these are deployed using a virtualisation technology enabling far more containers to run on a host than VMs. #ContainerSprawl is inevitable.

Whilst Microservice architectures and containerisation are undoubtedly a step forward for developing and deploying applications by their very nature they require greater management to ensure the flexibility does not compromise the delivery and availability of applications/services. They enhance the reasons for Deployment Automation tools rather than diminish them.

Found this interesting? Why not share it: