Serverless is still a buzzword but what does it mean in terms of applying serverless patterns in enterprise architecture. This article is inspired with AWS training I took and patterns presented in one of the modules of the lecture.
For large enterprises, that have number of legacy systems, serverless is still vague goal. Not only is it difficult to apply those patterns technically but concept usually escapes legacy IT personnel. Legacy systems, monolith applications, are usually very difficult to migrate to microservice architecture or decoupled services. Serverless is even more difficult to implement.
What does serverless means in those enterprises and how can such enterprise implement new architectural patterns and technologies ?
Operational model evolution enables teams to independently deploy infrastructure and code without the need for operational overhead.
Modular Services
Architectural patterns describing decoupled systems, microservices and serverless systems have similarities and differences. Legacy applications are designed usually as single system, possibly divided in modules but deployed on dedicated hardware as a whole.
Having single application with large number of modules and functionalities makes development of new functionalities very difficult and time consuming. Single change can cause cascading failures and cause critical loss of functionality. Testing this type of application can cause delays in deployments and increase cost of operation. The bigger the application the more time you need to keep it updated or to develop new features and functionalities.
Modular services pattern works with single business functionality that is decoupled from other services, independently developed, maintained and deployed. With loose dependency, those services are easier to develop and maintain but bring complexity in the application landscape.
As Managed As Possible
Monolithic applications have designated hardware that runs application, maybe based on three tier architecture, resulting in enterprise IT managing servers and IT infrastructure.
Operational model evolution enables teams to independently deploy infrastructure and code without the need for operational overhead.
Operational model evolution follows computing evolution, causing paradigm shift that not only relates to managed infrastructure but also changes how we design and develop applications. True benefit of the cloud can be seen in full when implementing cloud native application and services.
There is also something to be said on cost saving when moving infrastructure to the cloud. Common pattern that is observed is that enterprises are applying is cost reduction from scaled infrastructure for periods of expected decreased load.
Serverless operational model lowers maintenance cost of IT assets, bare metal and internal networking.
Computing evolution from physical machines to virtual machines enabled enterprises to leverage managed infrastructure and to enable scaling based on frequency of peak loads. But in that architecture pattern IT still needs to maintain hardware that runs virtualization platform, network infrastructure, OS’es, software patching, security…
Moving virtual machines to the cloud removes the maintenance of physical hardware and in some part maintenance of OS releases and security patches. Deploying cloud instances on supported OS’es will in some part enable IT to apply OS upgrades in mostly automated processes but it still remains the responsibility of IT. On what is called shared responsibility operating model IT will still need resources that manage underlying system and architecture.
Decoupled data and storage services improves fault tolerance. Decoupling state from servers improves resilience and handles error cases better.
Database services are also changing in way that reduces management efforts. Cloud database services enable spinning up databases on demand without having to manage underlying OS, or apply security patches.
Storage as a cloud service can also reduce operational and maintenance effort. Solutions like managed disks, or VM’s with NFS can enable access to storage solutions needed for your applications but still require certain effort to manage. But you don’t need to purchase, install and configure your storage solution, you deploy it with few clicks or few lines of code. As far as truly serverless solution there are options like S3 buckets, Google storage or Azure storage where you can deploy storage solution without additional maintenance effort.
Other services, like messaging, event streaming, monitoring, logging are also present at the core of cloud native solution and real benefit from those services can be seen when designing and developing truly cloud native applications.
Adoption of cloud services can leverage scaled infrastructure and cut down on operational cost. But cost of operation for cloud services is not so straight forward. Enterprises that have on premise cloud, running Kubernetes cluster in-house don’t have real benefits from cloud deployment. It is cheaper to spin up dev environment in house that to deploy it in the cloud — specially when on premise infrastructure exist and is running.
In large enterprises cloud governance can be as heavily regulated as any other. And having the speed of cloud deployment will soon be diminished by operational procedures and bureaucracy.
Serverless business strategy in agile environment
Developing business strategy around serverless patterns means that enterprises can focus on delivering value rather than managing and facilitating resources needed for value delivery — managing and maintaining infrastructure, primarily.
Deliver best from the cloud, as serveless first strategy leverages the best of cloud strategies:
- No server management
- Flexible, automated scaling
- Pay for value
- Automated high availability
To facilitate cloud services, agile teams should manage cloud resources needed by the team to deliver value to clients and cover costs that these resources consume. This will drive the team to optimize their solutions and cut down on cost. This approach would enable the team to manage their own infrastructure and deploy needed services faster.
Role of Enterprise Architecture in this environment is to drive the teams, to clearly map enterprise goals to target architecture, to establish security and compliance guidelines that teams should follow. Through defined templates for service deployments, EA can define service configurations that will apply those guidelines more efficiently and enable updates of those guidelines seamlessly in the future.
Of course this is not everything, and application of those patterns will depend on the enterprise landscape, goals and enterprise culture.