Today, agile approaches are gaining momentum in the corporate world. The goal behind this new way of building software is to reduce the time-to-market functionality offered by these products. It is also in order to get regular feedback from different stakeholders to continuously adapt products. In this way, companies can respond better and faster to the changing world around them. On the other hand, the explosion of cloud services in recent years, and more recently, so-called serverless approaches offer businesses the means to worry less about the infrastructure of their information system.
Web giants, such as Amazon, Google and Microsoft, allow IT to consume the infrastructure services they offer. This allows them to focus solely on their business needs. As a result, companies gain flexibility and time to develop their own services. Time-to-market is mechanically better.
Given this observation, isn’t there a union to be made between agility and Serverless architectures offered by Cloud Providers? What do businesses have to gain from this marriage?
The architecture of an SI must be agile
Being more agile happens through a new methodology
Today, when we talk about implementation of agility in business, we naturally think of the adoption of new work methodologies
such as Scrum, Kanban or SAFe, which
are the most widespread. Without going into the details of these different
approaches, their objective is twofold:
- Minimize the tunnel effects between the expression of a need and its delivery in the form of a software product.
- Regular introspection of the software product and how to work in order to adapt as soon as possible. And deliver a product with maximum value for users.
Agile methodologies : a non-sufficient necessity
The adoption of
an agile methodology is necessary, but not sufficient to
make the development of an agile software product. As mentioned in the
introduction, the ability to adapt a software product at any point in its
development cycle is the main characteristic of agile approaches. Therefore,
the code, itself, must also have this ability to adapt as easily as possible
and especially without compromising its stability.
The agile methodologies cited above do not address or
minimize software engineering practices to ensure that they have an adaptable
code. They must be complemented by
design and development practices from XP (eXtrem Programing) and Software
Craftsmanship. Among these practices, is to mention the most emblematic:
TDD (Test Driven Development). This technique involves addressing the
implementation of any new feature through a series of cycles that include the
following steps:
- Development of a failed test
- Development of the minimum production code to pass the previously developed test
- The refactoring of the written code to make it as clean as possible
Thus, this practice makes it possible to have a
testable code and tested permanently. And thanks to continuous refactoring,
ensuring a high level of quality (readability, maintainability, …) thanks to
continuous refactoring. The code is more easily adaptable throughout the
development cycle without compromising its stability.
Finally, despite the adoption of an agile methodology and software engineering practices made to be more agile, organizations can still encounter obstacles to make their information system agile. Isn’t there a reflection to be made regarding the architecture of the SI in order to make it completely agile? At INVIVOO, we believe that transforming an organization to be more agile also involves thinking about the architectural choices of its IS. Some architectures bringing more modularity and flexibility to the IS as a whole make it more adaptable to change. And this happens without having to rethink, in large part, each of these changes.
Agility through serverless architectures
The contribution of architecture microservices
The microservice-based architecture consists in
developing a software solution not in the form of a monolithic product, but by
means of several services communicating with each other. Each has its own life
cycle and with the smallest possible granularity for each service. The purpose
of this architecture is to minimize the impact of a change on the code. Indeed,
a change in functionality impacts a known list of services by ensuring that
there is no impact for other services. This is possible because the internal
code of each service is perfectly isolated from the others.
On the other hand, a change in the execution environment of a service does not have any impact on the other services because each service can have its own runtime environment, which is impossible to guarantee in the case of a monolithic architecture. An architecture based on microservices is naturally more adaptable and therefore more conducive to an agile IS.
Serverless architecture : one more step towards agility
Serverless architectures, may it be Back-end as a
Service (BaaS) or Function as a Service (FaaS), push the microservice
architecture a step further. Indeed, they offer developers no longer worry
about the deployment infrastructure, the execution environment and, therefore,
possible scalability issues. For this, they rely on Cloud solutions. The Serverless approach is therefore also
very close to the precepts of agility for various reasons:
- It increases the focus of development teams on the business code of applications. Therefore on what brings value to users. Development teams have less to worry about some technical bricks provided as services. Deployment issues are handled by the provider of the Serverless platform. Like agility, a Serverless approach promotes regular delivery of business value.
- It makes any application scalable, and this in a transparent way for the developer. Like agility, a Serverless approach facilitates adaptation to change (especially at the execution level).
- By focusing on the business code, collaboration between the development team and end users is facilitated. Like agility, a Serverless approach advocates collaboration with the customer.
- A Serverless platform often provides technical bricks as services. These services make it possible to quickly realize POCs and to adopt a Fail-fast approach. Like agility, a Serverless approach promotes quick feedback on the viability of a solution.
- A Serverless approach reduces the time needed to make a feature available by allowing teams to not worry about deployment issues. Like agility, one of the goals of Serverless approaches is to reduce
Conclusion
To conclude, making an organization more agile is not
just introducing a new methodology to manage its projects; it is also
introducing new development practices and new architectures. Among these,
Serverless architectures are clearly conducive to greater agility in
information systems. It would be a shame to deprive oneself of it.
