Policy automation over misconfiguration
In this post, we look at how Altostra can help you deal with common delivery concerns, freeing your developers to focus on the business requirements.
Originally published on Altostra.
When starting new software projects, it’s often easy to neglect some of the most critical aspects that will matter a lot down the road. To mention a few: security, logging, monitoring, alerting, error handling, etc.
Rightfully, this is not done by neglection but to save time and focus on the essential parts first, to figure out the design before plugging it into the Matrix.
Of course, there’s also a dark side to it. If we forget to address these concerns, problems arise when the project is delivered, and we discover that some parts are missing. Logs are not shipped, alerts are not set, and that dev environment we’ve been using for testing is now inflating our AWS bill for no reason.
Cross-cutting “not now” concerns
Developers shouldn’t worry about those concerns, at least not at first.
When you start a project, you don’t always know what it’s going to look like. You add, change and remove modules and components until you settle for a good design. If you start by investing heavily in the surroundings, you might find yourself throwing much of it away because of requirements and design change. On the other hand, these are critical concerns that should be addressed in every software.
You must also remember that adding these aspects late is not trivial. You must make sure you wire all the right locations and configure everything according to the environment you deploy to. You must make sure to use the correct API keys for SaaS services and much more. The longer you delay, the harder it becomes.
Ideally, you would have all that automated right from the start.
The road to peace (of mind)
With that in mind, let’s look at two examples of policies that Altostra provides for control over deployment environments.
Our customers commonly use the Log Shipping policy to ensure all deployed Lambda functions send logs to a 3rd party log aggregation service. This beats the alternative of configuring it manually as we once did in a previous post.
Another commonly used policy is auto cleanup of development environments. You set a TTL for an environment, and Altostra deletes any deployed instance that hasn’t been used for that period. Remember that although Lambdas are free while dormant, other resources are billed by the hour for merely existing. We also don’t want junk on our accounts, for security and other reasons.
By automating these concerns, developers who work on new projects don’t have to remember to configure their Lambdas for log shipping. And developers who come back to extend a project don’t need to remember to add log shipping for every new Lambda they add. This is even more critical in the serverless universe as Lambda functions are fundamental in most projects.
What if I have other needs?
Our goal is to empower developers by providing ready-to-use tools and by leaving room for custom solutions. We are continually working on providing policies to fit the common market needs.
Nevertheless, like with any abstraction, not everyone’s needs can be satisfied, which would make the solution less usable.
Take AWS, for example. You can come up with amazing serverless solutions by gluing various serverless services together. But, when you need to do something custom that isn’t supported natively, you use Lambdas to inject your own code. Altostra does something similar with its abstraction layer over the cloud services. For example, you can inject custom CloudFormation templates to fill in for missing resources.
To avoid roadblocks and provide users with agility and flexibility, custom policies enable the injection of code into the deployment pipeline.
That gives room to come up with custom solutions where one isn’t available yet.
Going forward
We strongly believe in automation and consistency to make our work more efficient and stress-free. From our experience with the market’s needs, we’ll keep adding more policies in the future.
Our advice is to create and set up automation for these concerns early in development to get them cheap. Or let Altostra do it for you. Either way, it will save you a lot of headaches down the road.
If you have questions, suggestions and ideas for more policies, feel free to contact us at support@altostra.com
