Manage Development Environments in AWS Serverless Infrastructure

A serverless platform provides an opportunity to give every developer its own separate full-stack environment on an AWS account that they can leverage for dev and test activities.

This is possible without significant costs increasing and impacting anybody else. Or without a risk that the developer’s setup will be changed accidentally. 

Serverless architecture gives a different view of the old problems and is positively refreshing in many ways. The foremost advantage is you no longer need administrators in the team to make no sacrifices in running full-scale processes. The other advantage – now oriented towards the internal development team rather than the business, is that it can serve the development team with limitless conditions for their development work. 

We are going to explain here what that means exactly, namely:

• How to create a limitless development environment setup in a serverless platform.
• What are the benefits of such a setup for the team?
• Most crucial areas to look after in such a setup so that it will not break over time.
• Demonstration example of such setup.

A Road to Standalone Environment Stack for Each Developer

You can look at the development infrastructures as an evolutionary process over time.

In the Beginning, There Was a Light…

The very usual way to manage development account environments is to create one or a few separate development environments. In a better case, they contain all the production environment components. Even this is not at all standard. Often development environment will end up limited to some of the most important services and missing the rest. 

Naturally, in such an environment, it is more challenging to develop a reliable solution. The impact on the non-presenting system components is simply missing. The management team will say that this can the team figure out later in test environments during system testing. However, this will never win an empathy achievement trophy in the eyes of developers.

Development activities will be less accurate. Developers will spend more time on reworking and fixing issues, and overall their motivation to create a perfect piece of code will go down. Besides that, with such a setup, you are already creating an inconsistent and unstable environment right at the beginning.

Depending on the size of the team, several development environments might be necessary to mitigate the most critical parallel work conflicts between the teams. As they will share the development environments, one developer will impact the other one in one or another way. Extensive communication between the team members is a must. 

More dev environments mean fewer conflicts, but sharing factor is still here. It might be workable, but it never will be a perfect setup. Most often, the developers will end up creating something (that is already in conflict) locally directly on the laptop machines. This might create additional problems later while merging the code. The behavior on the laptop machine can be different from the one on the cloud. This can create problems after merging the code with the developments already done by the others.

But Then Somebody Created the World…

The obvious question now is – what it is then? What setup would remove sharing factor and would not motivate the team to do activities elsewhere besides the cloud account?

Imagine every team member getting a separate environment stack that they can use for their own activities. It would consist of the same components as the production system. Sans the full data load as that is something you don’t even really want for development activities.

Or let’s go one level up – what about creating such a stack for each task the developer is working on?

Expensive – you might think.

Not really – I would say.

If the developers are actively using the environments and their resources, then the load comparison between doing it all in one shared environment in parallel versus splitting them into more environments is very likely to be equal in terms of costs. Because you have serverless architecture and you pay only for the real usage.

If the developers are not active and they still have created this full stack (or more of them at the same time), the cost is zero because you have serverless architecture. Services not in use generate no costs.

Let’s talk about the benefits more closely.

Benefits That Only the Development Team Can Appreciate

First of all, one thing is very clear. All the benefits this setup provides can be appreciated only by the development team itself. No management or business user will ever see value in this. I mean, they might understand where the value is. But most likely, they will never admit they absolutely need it. They don’t use it, and they don’t see it in their day-to-day job.

But how hard it really is to understand that the best development results can happen only in the best working environments?

So here are the benefits:

1. The developer has a certainty no one else will change the environment that they are currently working on. All components are created newly just for this task and development activity. 
2. The development environment is an exact copy of the production environment. This means accurate simulation of the code changes behavior is possible
3. The team will always develop directly inside the cloud account, as there is no point anymore to do it locally.
4. Assuming you have built DevOps pipelines for environment creation and update, you can integrate them with Jira or ADO tools for stories and tickets management and create or terminate the dev environment together with stories progress and closure. This will give you a separate dev environment per each story. Or even a task inside the story, for that matter, which is really great for backtracking purposes.
5. Whenever the developer commits a change to the code repository, the pipeline will update the environment with the latest repository code. This means deployment automation when building new code and faster unit testing processes.
6. No regular maintenance of development environments is really necessary. Each environment exists only for a specific short time. It is created always from the latest repository code state and latest data snapshot. The maintenance problem is self-resolving in this case.

What Are the Drawbacks?

Yes, there are some caveats to be aware of. I wouldn’t call them disadvantages explicitly. However, if you will not pay reasonable attention to the things below, it is very likely that, over time, they might grow into your reasons for infrastructure refactoring actions.

#1. Watch Out for AWS Limits

Here is the thing. If you are going to create a separate environment stack for each person and activity, then you are going to create a lot of AWS objects.

Think S3 buckets, policies, roles, users, databases, VPCs, and so forth. 

This is a must for you to overwatch and monitor. If the environments will be just created and developers will add more and more of them without properly deleting the old ones or those related to already completed stories, sooner or later, you will run into issues with reaching various AWS limits.

Some of them are easy to increase. Others you can request to increase via AWS support. And then there are some hard limits which you can’t do anything about it once hit.

This will be a game about controlling the overall number of used AWS objects per each object type. It will be about making sure you are not constantly dancing on the edge. You don’t want to be most of the time in the upper area of the limits. That would effectively mean that before every new environment creation, you need to first deal with some cleaning processes, manual or automatic. 

Either way, this will only result in the effect of slowing down development activities overall. The development team will be constantly in some process of resolving existing environments first before creating another one.

Instead of this, what is really crucial is to keep all the limits in check proactively by doing some constant background housekeeping. Ideally, in an automated way so that the next time a developer needs a fresh new environment, they create it right away without any further delays.

#2. Keep the DevOps Pipeline Execution Time Down

It sounds great saying each new development environment will be created automatically once you start working on a story.

It sounds terrible if, in reality, that means the developer will wait for such an environment few hours. And then not only for the creation but for each consequent update of the environment (right after each repository commit).

Put it into a summary formula and see how much idle time would generate such a situation. It’s not really possible for a developer to jump to “something else” every time they need to wait till the environment is ready. 

That would be like expecting you to go shopping while waiting in the doctor’s place for your planned check-ups. It’s just not going to happen. You sit there and wait because it might come every next minute.

#3. Regularly Update Master Dataset

Every new environment creation must have a referral source dataset. This serves to copy over the data to the just-created environment stack. The dataset must be regularly updated (basically after each production release). This will ensure the environment is created with the latest dataset structure. 

It does not need to contain a full database snapshot from production, although that is usually the simplest way to do it. However, the data model must be always up to date so that every new development activity starts from the right starting point.

#4. Teach Your Team to Be “Environment-Responsible”

Being eco-friendly is now a big topic and expectation from all major companies. Similar expectations shall apply also to the development team.

If one developer needs more environments in parallel because it will significantly increase the effectiveness, then so be it. But if, on the other hand, the developer keeps open several environments in parallel just because they are lazy to close them, then that is something to heal as fast as possible. 

Having the privilege to work on a private sandbox shall come with an adequate level of responsibility. We shall expect nothing less than responsible and solidary usage of such benefit.

Example Setup

Now putting it all together, here is what to expect from such a serverless multi environments setup.

• You can use the DevOps pipeline to automatize new environment creation, update, and termination.
• Then the developer will work on and update the dev environment as he progresses in the development.
• Once the developer finishes with code changes and unit testing, conclude the activity on this environment by merging the code to the master repository branch.
• Since many developers can do this simultaneously, code merging activities are necessary to ensure the transfer of all the changes from the development environments to the single place of true – the master branch.
• Update the central testing environment with this master branch repository state so that the system testing activities can be performed over the merged code from all the developers.
• Use a dedicated Bug Fix Environment to resolve any ongoing issues. This environment can be created using the same DevOps pipelines already in place (just treat it as another temporary development environment).
• Finally, proceed to QA testing and production release.

As you can see, by reusing the same DevOps pipeline on different stages of the architecture, you can quickly build a flexible serverless platform with as many standalone development or test environments as needed. Best of all, all the benefits will not come at a cost.

You may also be interested in these serverless computing platforms to run your code.