Microservices and Docker Containers are the focus for agile delivery of web-applications in today’s IT world. Modern applications are stateless, singletons and are deployed on mass to cloud environments via various Platform-as-a-Service hosting environments. For folks writing new applications for the first time this approach is great, it is very quick and easy to get new applications up and running, but what about everybody else? What about those with large investments in traditional on-premise applications hosted in monolithic middleware? How do you tackle the problem of moving such applications in cloud first container based microservices?
A transition from the old way of doing things into the new is daunting to say the least. Often IT departments don’t even bother, simply freezing further development on older platforms and forcing new applications on to new cloud first container based environments. This can work, but leaves the IT department with the need to manage two very different environments, which over time has an impact on costs. There are ways to go about making the transition and I would like to briefly touch on two aspects of making such a move from monolithic middleware to container based microservices; refactoring the code and transitioning the infrastructure.
Refactoring the code
Refactoring the code is the part of the iceberg that is under the ocean and not seen, but is by far the biggest and most daunting task. Applications that are stateful must be redesigned to be stateless. Large Java applications contained within an Enterprise Archive (EAR) must be broken apart into separate Web Archives (WAR) with one application per runtime. Inter-process communication must be redesigned to take advantage of Representational State Transfer (REST). Databases need to be broken down into separate (perhaps nosql) based data solutions.
The list goes on and on. This can be a daunting task and unfortunately there is no magic button for this aspect of the transition. There are plenty of guides out there on the Internet and subject matter experts to help you with the transition (including our Tech Data consultants). I point this out as a warning that simply chopping up the application and hosting it in separate container based run-times by itself is not enough, these interconnections and cross dependencies must be addressed and decoupled as a prerequisite.
Transitioning the Run-Time Quickly and Create Consistency Across Traditional Middleware and Microservices Based Docker Containers
Prior to refactoring, it is possible to automatically break-up the monolithic environment and transition it to microservices container based run-times. By leveraging Tech Data’s Talos solution, you can automate this process. This approach can help you understand the interdependences between your applications. Also it will help you identify the applications that can be containerized ‘as-is’, versus the applications that will need a little work (see previous section).
In addition, it is possible to manage both monolithic middleware and microservices environments. By leveraging the same set of tools and transition configuration changes across both environments, management is far quicker. For example, say developers work in a local containerized microservices based environment, but production is on shared monolithic middleware. Then Talos can help normalize your approach, allowing deployments to happen to both environments in a consistent way. This saves time and reduces costs.
Talos does this by automatically discovering and importing traditional middleware environments. With Talos, it is possible to break-up the middleware configuration into independent application centric templates (for example WebSphere Application Server). These can be converted automatically to leaner microservice run-time environment templates (for example WebSphere Liberty Profile or Tomcat). The templates can be leveraged to create Docker based images. Talos contains a wizard for creating microservices based run-time Docker images. It is then possible to map these application centric templates and build your new container based Docker image right inside Talos.
In summary, it is important to look at the underlying code and refactor your applications. Equally, you should adopt an automation process for the migration to and the long term management of your container based Microservices environments. This process should be consistent and compatible with your monolithic middleware DevOps solution. Here, Talos can help. When done right, we often see a reduction of up to 75% in the migration time, a large reduction in errors and a stronger long term DevOps strategy. There is no better time to adopt a new automation process than when performing a migration. This is because you can avoid disturbing the existing processes while piloting a new one that will ultimately accelerate the migration.