Cloud Native: Meeting the need for speed

The need for speed

It’s hard to deny that the pace of change has quickened dramatically. COVID 19 has had an impact on the businesses which we could not have imagined only a few months ago.

Many companies were considering moving their businesses delivery from face to face to online. These “digital transformation” projects had timescales measured in years. When lockdowns were introduced, they had to achieve this in weeks.

Many companies were considering pilot projects to see how employees would work from home. To address security, communications and workspace quality considerations, projected timelines were once again measured in years. When the virus came, they had to do it in weeks.

There is no evidence to suggest that the pace of change will slow down any time soon. IT solutions and solution providers need to adapt as fast as the changes happen themselves.

Traditional (Monolithic) software development

Traditionally, applications have been developed as one massive block of code, with a single database, a single directory hierarchy and deployed on what is essentially a single file. This is known as “monolithic” architecture.

Deployment of these applications is simple. There is only one file or block of code to deploy. Scaling is simple when you need more of the application, the load balancer will have the file copied and another instance created.

There are disadvantages, however.

Everything is contained in one block of code. Everything depends on the same database. Everything is part of the same directory hierarchy. This makes even the smallest changes difficult to implement without affecting other parts of the application. To install any change, the application has to be redeployed in full.

Even starting the application will take longer, because there is more of the application to start. This slows down testing since every test needs a deployment and restart.

It is difficult for newly recruited developers to understand the whole application because there is so much of it. However, they need to create code for new components which can be affected by and can affect in turn, almost every other part of the application.

This volume and complexity mean that new releases with new features are few and far between. Software developed in this way is slow to adapt to changes.

As the application is enhanced, it grows, it becomes more complex until it collapses under the weight of its own code.

Microservices – the key to cloud-native development

Cloud computing has given birth to a new development architecture. This is based on microservices. Any cloud-based application these days will be made up of a number of microservices.

A microservice is a part of the application designed to function independently. Each microservice will have its own database and not depend on a central hierarchy of directories. A microservice is a mini-application within the application.

Taking an example of our Agent Desktop application for Amazon Connect,  we have multiple microservices where one microservice provides CTI controls and handles the telephony part of the system, another covers the data population and a third that integrates with Amazon Connect itself and so on and so forth.

Each microservice can be developed and deployed independently of the others. They can be stored in separate containers. A change to one microservice will not affect the other microservices, and an issue in one will probably not affect the rest. Each microservice can also be tested independently of the others.

Small teams of developers can be assigned to work on each microservice without constantly having to coordinate with the other teams. They can make their own changes and test them independently This speeds up development considerably. Applications, such as our user desktop for Amazon Connect can have enhancements and new features added continuously.

The small size of microservices means that a developer can be assigned to one microservice without having to learn the whole application, so she can become productive faster.

Microservices, being smaller, can be deployed and started faster. This allows for more frequent testing iterations and therefore the introduction of new features and enhancements.

There are, however, some disadvantages.

Microservices having to communicate with each other adds an extra layer of complexity to the application.

A collection of microservices may use more memory than a monolithic application because each microservice has its own container and database.
Deploying the application as a whole is more complex. Each microservice will be deployed separately and then connected to the others.

Modularization applied to software

The concept of modularization is nothing new.

Many modern buildings, such as hotels or schools, contain identical elements such as rooms for guests or classrooms. They are built on a modular basis. Elements can be pre-fabricated in a factory and then hoisted into position using a crane. Using these construction methods, the Chinese recently constructed a 15-story hotel in only 2 weeks.

Shipbuilders today have replaced the “monolithic” approach of laying down a keel and then building upwards with assembling the ship from a series of “blocks”. The Royal Navy’s new aircraft carrier, HMS Queen Elizabeth, was built this way in only 6 years.

Aircraft manufacturers adopt the same approach. Both Boeing and Airbus assemble their airliners from components brought in from hundreds of suppliers. At full production, these companies can produce more than one airliner per week.

Now the principle is being applied to the development of our software applications for Amazon Connect. It is changing the industry in much the same way that modularization has changed construction and manufacturing, by meeting the end-users’ need for speed.