DevOps in a Serverless Environment: The Common Blind Spots
We’ve discussed the benefits of serverless at length and talked about the advantages of DevOps in a serverless environment. You can understand why serverless DevOps is so crucial to your success, but beware of some common blind spots that can derail your serverless DevOps implementation.
Not addressing these challenges can cause an implementation which is meant to increase your efficiency to actually slow you down. Here you’ll find some of the most common blind spots — and how to avoid them in your serverless DevOps implementation.
Blind Spot 1: Serverless DevOps is the Same as Non-serverless
What to Watch Out For
DevOps in a serverless environment is fundamentally different, just like developing microservices is fundamentally different than working on a monolithic application.
Deployment models must completely change.Instead of having a single large application to deploy, DevOps must manage the release of many small serverless services that fit together to create one cohesive system. This requires a different way of thinking and planning, down to script development and timing.
Processes also change when in a serverless environment. It’s important that developers know what microservices to code against. Good naming conventions are critical for clarity. Commits and features to a microservice must run the correct automation and deploy code to the right microservice.
Actions You Can Take to MitigateThis Blind Spot
To be successful with DevOps in a serverless environment, you’ll need to change your mindset. Doing so will change your processes so you can scale to accommodate the multitude of microservices that need to be deployed.
Traditional DevOps models will no longer cut it. Instead, DevOps teams need to think about handling many hundreds or even thousands of microservices that make up an ecosystem, instead of a single, large application with many moving parts. Plan to scale your development processes and deployment automations well into the future to create a seamless experience as your serverless footprint grows.
Blind Spot 2: Planning and Defining Your Process Before Implementing Automation
What to Watch Out For
It can be tempting to create automation for a single microservice’s deployment simply to get things going. Doing this can cause a problem as you can get stuck doing that every single time you have a new microservice. You’ll end up cloning that process and creating CI/CD automation for each microservice over and over.
Taking the time to create development processes, standards, and a scaling model at the start of your DevOps journey will prevent falling into the trap of one-off automation. It might feel at the beginning like you’re saving time, but in truth, you’re just adding to your technical debt.
Think of automation of microservices deployment like onboarding — each item brought into the ecosystem should go through a standardized, well-defined, and designed process. Automations then adhere to the process, instead of creating a process for each microservice. This offers a better developer experience, as well.
Actions You Can Take to Mitigate This Blind Spot
When you add microservices, create templates and models that speed up onboarding. It can culminate in onboarding checklists. Process development should be done from the beginning of your DevOps journey. Every new development should be part of the process.
Once designed and defined, be sure to enforce your process as well. There are many ways to do this, including locking a developers’ access who doesn’t follow the rules. They must follow the process if they want to stand up new Lambdas in AWS for example.
That doesn’t mean developers should be locked out of the design process, however. Collaborate with them on implementation to make for a great developer experience, and collectively iterate on these DevOps processes to improve on them.
Blind Spot 3: Scaling Your DevOpsProcesses
What to Watch Out For
It’s short-sighted to assume you’ll only have a few microservices. If you start with that mentality, you’ll end up with processes that work today, but need to be completely re-designed tomorrow when your serverless footprint inevitably grows.
DevOps is all about speed and efficiency. When you plan processes that will be difficult to adopt at scale, you slow down your pipeline and create a poor developer experience.
Actions You Can Take to Mitigate This Blind Spot
No matter how many microservices you have today, plan as if you have 100 times that amount. In our experience, we’ve never seen an AWS serverless implementation that contained fewer than 5 AWS Lambdas. As you add connectors and increase connectivity, it will only go up from there.
Typically, there are two ways to do this. You can either allow a single process and automation to dictate all deployments, or you can create great onboarding processes for developers developing new serverless microservices that deploy individual or smaller chunks of the system.
If you’re not sure how to do this, remember that you’re not alone. Don’t be afraid to call in the experts. Teams at AWS and the team here at Big Compass can help you look at your specific environment to design the right, scalable solution.
Blind Spot 4: Communications
What to Watch Out For
Historically, there has been a breakdown in communication between admins and developers. With the emergence of DevOps, that can be transferred to a communication breakdown between DevOps engineers and developers.
Communication is a two-way street, but there seems to be a gap between these groups. DevOps engineers can come in, implement great processes, and call the project done, without ever speaking to a developer. In the end, developers are users of the DevOps processes and automations. Without buy in from developers, your organization won’t realize the efficiencies that the DevOps team strives to achieve.
As always, silos are a killer.
Actions You Can Take to Mitigate This Blind Spot
It’s up to DevOps to evangelize their processes to developers. DevOps should encourage collaboration, and the process should be communicated and enforced in coordination with the developers.
Forward-thinking organizations might consider intermixing DevOps engineers with development teams. This is especially effective when an implementation is already in place, and DevOps is being added after the fact. For example, a DevOps engineer could be attached to a team of five developers who are already working on a current solution.
Either approach allows DevOps engineers to garner alignment and obtain buy in during the design phase before the DevOps implementation begins.
Blind Spot 5: The Perception ThatServerless Implementations Can Be Successful Without DevOps
What to Watch Out for
This blind spot may sound a little radical. You CAN indeed be successful with a serverless implementation without DevOps.
But that thinking is myopic. The reality is that long-term serverless integration success is a challenge without DevOps. It will take a lot of time to support and maintain your ecosystem, which, again, is counter to the speed and efficiency gained with the right DevOps processes.
Why? Because without solid DevOps in place, your governance and maintenance will get out of hand quickly as your serverless footprint expands. There is an economy of scale that DevOps achieves, and without it, you risk slowing things down.
Actions You Can Take to Mitigate This Blind Spot
Serverless implementations go hand in hand with DevOps. There is no getting around it. As you plan to implement projects using serverless, you should bake DevOps design and implementation into the plan.
Blind Spot 6: Is it Measurable? DevOps Can Be Taken for Granted
What to Watch Out for
What does a successful serverless implementation look like for your organization? How will you know if you’ve achieved it? More importantly, how will the CIO realize you’ve achieved it?
You have to be careful about implementing DevOps without planning how to measure it. Not only will it set you on the path of continuous improvement, but it will also clarify to leadership the value of what’s being done.
Actions You Can Take to Mitigate This Blind Spot
Start with a baseline of your measures before DevOps is implemented if you can. If you’ve already started, take a look back at sprint retrospectives and velocities as well as other key measures that may already exist.
From there, define your measurable metrics. Some common metrics are:
- Deployment success rate
- Feature development efficiency
- Bugs caught in QA
- Production downtime
- Number of rollbacks
- Time to deployment
- QA time
- Sprint velocity
Once your DevOps processes are in place, communicate the new metrics and current data. Use email and dashboards to share the information with developers, ops teams, and IT leadership. And don’t forget to use those metrics to define enhancements or improvements.
Serverless with DevOps is a powerhouse. But realizing the success can be derailed if you’re not aware of blind spots that will slow you down.
