It’s an interesting time in the IT industry. Architectural approaches come and go in waves. SOA was a hot topic going back five to 10 years ago. It seemed a great idea on paper, but alas the implementations of SOA that manifested in the market place were overly complex and as a consequence the uptake of SOA fizzled out. SOA is just one example, there are of course many more. We are a few years into what has become a rallying cry in the industry; that is this need to be agile and move to a microservices cloud first architecture.
This push to ‘smaller is better’, comes off the back of nearly two decades where the focus was on big monolithic middleware hosting various applications. In this monolithic world, scaling was handled by the middleware. Various configurations were managed via well-defined configurable sub-components within the middleware. For example, as an app developer you didn’t worry about how to connect to a database or message queue in a Java middleware environment. There were providers and well-defined interfaces for that. Applications were deployed to shared multi-node ‘clustered’ environments. These applications relied on the middleware to handle all the scaling and governance around how to configure and manage your application.
(image taken from https://blog.philipphauer.de/microservices-nutshell-pros-cons/)
Over time, complaints in the industry began mounting that a monolithic approach was difficult to maintain and scale. For example, clusters, in practice, can only be built to a certain size. Additionally, you have the challenge of projects with different release cycles butting heads when it comes to timing releases or upgrade/patching coordination to the middleware. What has followed has become known as the microservices revolution. Recently, I hear IT folks use monolithic middleware and the word legacy more and more interchangeably. It seems things are changing and we are in the throws of a major inflection in how we design and deploy applications to the web.
In truth, there are advantages to both approaches, there is a level of control and governance that can be appreciated with the monolithic approach. Whereas microservices provides a level of freedom and agility not afforded to those developing in a shared monolithic environment. Of course, such agility comes at a price; governance is now decentralised and left to the developers’ discretion, meaning they are much more in the driver’s seat.
At any rate, this blog could go on and on about the virtues of microservices verses the monolithic middleware approach, but that isn’t the direction I was looking to take things. The reality is, for better or worse, organisations are making the shift to an agile microservices approach for hosting web applications. This is causing IT teams to rapidly adapt, whilst still trying to maintain their ‘legacy’ middleware needed to host their existing core applications. In response, many large organisations have created ‘digital teams’ tasked with developing new microservices friendly architectures and operational models. However, these teams often work in a vacuum and don’t communicate with the operational team in charge of ‘keeping the lights on’ or managing those monolithic middleware environments. Therein lies the problem. This divergence results in a two-speed approach to IT, burdening the organisation with extra complexity as it tries to transition their legacy applications over to a microservices environment.
The divide is certainly a barrier to the broader adoption of microservices. Both teams continue to ‘dig in’, but fail to look up to see how the other side is getting along. This communication problem has been articulated often in DevOps conversations. This communications “wall” described often in the context of DevOps, can100% be applied in the same way to the digital and operations teams for the management of middleware.
The key is to address this divide head on by approaching it from multiple fronts:
1.) Communication – This is a no brainer, but has to be said. Open up lines of communication between the teams, invite key individuals from the other side to your stand ups. Run any ideas on how things are done today in collaboration with the digital team and of course the digital team should be sharing their vision of the future. That vision should take into account what is being done today. None of this can happen without proper communication!
2.) Agree on tooling – It is important that both the digital and operations teams agree on a common set of tools. Automated deployments are critical in a microsevices world, as this is the only way in which it is possible to scale and add governance to the equation. If the digital team lays down a whole new set of tooling that operations currently isn’t using, then this is going to cause challenges when applications go live. Such a failure would result in a steep learning curve being applied to the operations team as they begin to get hands-on with the new approach. In addition, both sets of tools would need to be maintained, etc. Ideally the entry points for deployments to legacy middleware run-times, as well as microservices run-times, would look exactly the same. You’d have a consistent interface to the world when it comes to application deployments. In recent times there has been an explosion of tools in the DevOps space (see below to name a few). The introduction of a digital team to drive a transition to microservices is a perfect opportunity to revisit tooling and shore up the tools in play in the DevOps space.
3.) Plan to migrate the legacy applications – Two streams of development (digital and operations) is not sustainable over the long run. Once the digital team has worked out an architecture, deployment approach and piloted the development of a few new applications, it is important to begin the process of migrating legacy applications over to the new microservices world. This will build momentum in the organisation and accelerate the adoption (and in turn benefits) that microservices brings to the table.
Finally, I couldn’t end this blog without mentioning Talos. We’ve focused on ensuring Talos addresses the world of legacy middleware and the new microservices run-time environments. So for instance, we support monolithic middleware run-times such as WebSphere or JBoss as well as microservices friendly run-times like WebSphere Liberty or Tomcat. We can also manage these in Docker with our Docker integration. Most importantly, Talos can help accelerate the migration from one to the other with our template translation feature. As an example, Talos could discover a WebSphere Application server cell and create a series of tokenized application centric templates (with a single application and it’s related configurations like jdbc etc). These new templates can then be transformed automatically to Tomcat or Liberty profile and mapped over to Docker base images. Automatically and quickly you could have multiple single application hosted Docker instances running for each app, whereas before you had all these applications in a shared environment. In other words, we can quickly translate between the world of Monolithic legacy middleware and containerized microservices allowing for a common consistant approach with a foot in both worlds.
In conclusion, the key to managing the digital and operations divide is open and frequent communication. Plus a focus on consistent DevOps processes, leveraging a common set of tooling. Also, you need a focused effort on migrating legacy applications from the monolithic middleware to the new world of microservices. Whether you take advantage of Talos, or some other tool sets, maintaining two separate approaches is simply not sustainable over the long run.