This will be a 3 part blog posting that will address a transitionary architectural plan, the first part of this transition is in leveraging Lambda to transition a static architecture to a more dynamically allocated utilization of your architecture.
Part 1: Environment Replication with Lambda
In several business situations once a technical architecture has established a strong sense of functionality, an architectural reassessment should be implemented to reevaluate several key variables which can affect extensibility, modularity, and usability.
For example, in the immediate timeframe certain technical implementations solve the identified functional problems but fail in the immediate identification of an extensible, modular, and useable system. Take the below diagram as an example.
As you can see from the above diagram, the development team is small and the application is owned by a small amount of people and can be deployed by a few amount of people, very quickly. This solves the immediate problem of providing functionality to a user base and growing your user engagement. The problem with this implementation is that it doesn’t account for the following problems you will reach as your technology team grows.
- How do you replicate your production environments for developers?
- How do you delegate application responsibility to sub-organizations in your larger technology team?
- How do you account for future growth in cost?
- How do you optimize for optimal utilization of resources?
These are just a few problems that arise from the transition of a monolithic implementation to a micro-services implementation that can leverage Lambda to assist with your infrastructure. Let’s first address environment replication, so you have on boarded a new engineer and he was not a part of the core development team and has very little understanding about the existing architecture and application.
It is a very bad idea to give a new untested engineer the capacity to access your production resources without properly assessing their skills and ability to understand your architecture in a very technically visceral way. A better architectural technique would be to give the new engineer his own account, with federated access to the production account, and then utilize a lambda function to replicate the entire production site to their account. The below diagram depicts the architecture visually.
Now this architecture allows you to leverage and control your production AWS account and authorize and control the new developers AWS account. As the developer generates more products that go into production delegate out more and more access to the production account. If you start transitioning your developers to owning their own AWS account they have the freedom to explore on several of the products that AWS offers, and if you are already fully vested in AWS then there is no barrier to empowering your developers to expand upon the products and current features of existing products.