Overview
Containerization and microservice architectures provide an infrastructure that can support the realization of many requests of the IT world, including faster time to market for products and supporting technologies features, scalable services, and improved customer experience through reduced downtime and upgrade processes. Some companies have seen many-fold increases in feature velocity with the potential of tens if not hundreds of feature and fix releases of software both for customer-facing and internal use cases. However, the road to these values is not always straightforward, given that not all software can simply be containerized and therefore run like a microservice system. Kumulus Technologies has supported numerous efforts, from blank slate development projects to application migration and re-architecture, to move towards a microservice and container enabled future. This process includes a number of steps including:- Technology modeling and migration assessment
- A multi-stage migration approach
- Re-architecture support and development
- Continuous Delivery pipeline development and engineering integration
- Ongoing training and system support
Background
A Fortune 500 telco provider is in the process of modernizing their internal development process for operational support tools and for customer service applications, and in doing so, they need to migrate their applications to a container-based artifact approach from a current RPM packaging model, as well as implementing a rework of their current release process to automate the end-to-end application delivery pipeline. The customer's applications are already multi-component but are not microservices based. While the bulk of their applications are not going to be rewritten to microservices models, there is still some level of rework needed to move poorly architected elements into a model that supports zero downtime upgrades, which is a more important metric for them and for their customers.Assessment
While some systems-level decisions had already been made, such as a migration to containerization of artifacts, and the decision to use both private and public Kubernetes based container management, many unresolved questions about the overall migration were still outstanding. We engaged in a set of applications and operations assessments to put together a strategy for enabling their containerization migration process, with a set of achievable metrics as the guiding factor, including the goal of zero downtime upgrades, roll-forward bug fixes, and a continuous deployment process to reduce time to market for new product features to months rather than years. The assessments were done at both a global systems level, determining the general process and procedure for both the migration effort and new development, and at the individual application level, with an eye towards supporting the system's metrics defined from the top level of architectural guidance. The results of the assessment were approved and supported from the C-level down to the engineering and operations management, driven as a mandate to improve both quality and time to market for their tools.Development and Integration
As a result of the assessment workshops and strategy models, there were two major outputs; a continuous integration (CI) pipeline model, and a set of application-level recommendations for the migration processes. The CI pipeline model defined a set of standard tools and procedures to be developed and documented that would lead to the ability of the infrastructure to automatically release qualified and tested tools into production. While not every team is able to initially leverage the model as defined, the goal is to move to this overall architecture over time, either by reworking application components that break the model (e.g. fragile data management systems) or by accepting and accelerating the removal of technical debt features. The application level recommendations were generalized when possible to define a set of general targets and repeatable (and more importantly automatable) development and operations practices. These efforts were not deployable in all instances, in some cases due to technical debt that has a high priority to be remedied, and in some cases due to 3rd party components and tools that may need to be developed out of the process. Kumulus Technologies has provided support both on the development front, in re-architecting components to be more manageable in the automated CI/CD model, and supported the pipeline development and default processes needed to make efficient repeatable use of the model.Education
In order to apply the learnings, recommendations, and developed integrations, it was important to integrate both general Dev/Ops focused training, along with system specific education processes. As major processes were shifted from manual or simple scripts to automated integration and delivery efforts, development, quality, and operations resources needed to update their skill sets to meet the needs of the new processes, not only from the infrastructure changes but also to the models for future development. While general education is a powerful tool for enabling the transformation we supported for the customer, it was also important to educate the management teams on the efforts, and how they were proceeding. This process was similar to the Agile development methods that are often effectively applied to the development process but applied to the entire engineering and management chain within the organization. Organizational change was also driven by the process, as engineers, assurance professionals, and operators started working more closely together on their now overlapping tasks and processes. By exposing the current state of development and operations in a more open fashion, expectations of the change process were better managed, providing a more consistent experience of the overall migration process.Results
While the process is by no means complete, the efforts are already showing solid signs of progress. Customer satisfaction is on the rise and is being attributed to the ability to address issues in the initial application that became the poster child for this transformation process. In addition, job satisfaction is improved among the development and operations staff as they are increasingly able to address issues and the technical debt that caused outages and customer issues. The customer still has many of their applications to migrate, and yet, the consensus is that the efforts are moving the company into a position to better address their customer's current needs, address competitive threats, and open new market opportunities.Download your copy of this "Transition to Containers and Microservices" whitepaper, click below.
Download Your PDF Copy
If you have further questions about this process, please feel free to contact us using the form below. We look forward to helping you with your efforts.