How do you stay competitive in the new era of IT? You have to transform. Nearly every enterprise in every industry is exploring digital transformation to drive new pathways to their customers, create new business opportunities, and improve operational efficiency. Modern applications require faster, more flexible infrastructure to meet the needs of today’s customers.
Traditional infrastructure is designed for a world where each application is built like a vast monolith, rolling out a new version once or twice a year in a large change window. Six months of changes would have to be done before you could roll out a new version. This made it possible to plan infrastructure with plenty of time before each upgrade.
Today’s enterprises want to be able to roll out new versions several times a day. A new means of development is needed, where each application is broken down into microservices, small parts of an application that fulfill their roles individually. At the same time, enterprises are introducing container platforms where small microservices are ideally suited to run as containers independently of each other.
In a traditional infrastructure, a company would have a development department for a large application, and once or twice a year, a complete version would be submitted to the operations department. Operations would then make sure that the application ran properly and securely. In order to manage multiple applications, a small number of platforms and databases were standardized. The operations department had significant influence on standards and infrastructure.
With microservices, things work differently. Instead of 2 departments, development and operations, a small team is built up around 1 or 2 microservices. The team is responsible for developing the microservice and for ensuring the code is up to the expected quality. Each team features a combination of development and operations, which is now commonly referred to as DevOps. It’s up to each team to roll out new versions of its microservice in a secure manner, and the team makes its own decisions on rolling back changes, should something go wrong.
So how does this effect the teams and the way they work?
- Each team is isolated from the other teams. This means that if a team does encounter problems or if developer resources become unavailable, the other teams are able to continue developing their microservices.
- There is no longer a strong operating organization to impose standards and force teams to choose a specific technology. Instead, there is usually a security team that helps the teams adhere to security policies, but without dictating technology choices.
- The teams are autonomous and can choose tools and technologies themselves, as long as their microservice does what it should, is accessible, and works with other microservices. A team can choose to build its microservice using Python in AWS with the finished services available there, while another team uses .NET and Microsoft SQL Server as the database in Azure, and a third team develops on-premises in a private cloud because they require integration with traditional systems.
- To manage the entire chain from code, through testing, to production, these teams use “infrastructure as code,” which means they write a piece of code that describes how the environment should look and the code can then be used to create lots of identical environments. You can also use version management with this code so that you always have up-to-date documentation of how the environment should look.
To successfully implement digital transformation and create new applications, a private cloud is needed, one that is multitenant and that can run all types of applications and workloads with ease at the same time without affecting each other. Enterprises can no longer plan several years in advance and instead must be able to scale in small steps on demand. An enterprise must be able to control the private cloud with API calls and code. Strong integration with container platforms is also vital. Finally, enterprises must be able to connect their private cloud to public clouds, provision a microservice in any of these clouds, and make it work together with other microservices.
