A few years ago, Netflix released an engineering blog post with a simple but surprising message: every team at Netflix would be standardizing on Java and Spring Boot for all their microservices. Netflix had invested more than a decade in building a wide range of in-house libraries and services. Yet they were giving all that up in order to use one consistent framework.
Consistency has always been important for the engineering discipline, but we’ve seen teams prioritizing it even more in recent years. Why?
Why standardization matters more than ever for engineering
There are several factors behind the rise of standardization:
1. Teams are moving to microservices over monoliths
To increase engineering velocity, many organizations are migrating massive monolithic applications into smaller microservices. The problem is, this introduces complexity. Without standardization across the org, every individual team will naturally develop its own ways of doing things, and all the benefits of microservices will be cancelled out by the resulting overhead and confusion.
2. Remote, asynchronous work is on the rise
As teams go remote and become more distributed, there’s a need to put more standard operational practices in place—because you can’t always turn to the engineer next to you for help. When there are consistent ways of doing things, people can work independently and asynchronously without getting stuck.
3. Organizations have access to better tools and resources
Software engineering is a young discipline, but it’s past the “move fast and break things” stage. Nowadays, if there’s something you’re trying to achieve with software, there’s a very good chance that you’ll find standardized tools and methodologies to get you there. All the more reason to practice consistency.
4. Rapid growth is the norm
If a tech company is doing well, the engineering team is likely to double or triple in size in no time. As teams get bigger and bigger, complexity naturally grows too. The only way to manage this is by putting standards in place—which will also help new hires hit the ground running faster.
5. Diversity and inclusion are more important than ever
While it might seem like standardization has nothing to do with building a diverse engineering team, in fact it’s the opposite. Standardization helps break down tribal knowledge and “in-groups” so that people from many different backgrounds can succeed. As the tech field is prioritizing inclusive hiring practices, consistency is key to making sure the internal team culture is ready to support diversity.
These are all compelling reasons to look into bringing more consistency to your engineering organization. But where should you start?
Where to enforce standardization on your team today
Consistency can mean everything from having standard processes, like post-mortems, to the way you implement those processes—like making sure that each post-mortem follows the same script across every team. While it’s possible to bring consistency to just about any aspect of your engineering organization, here are some key places to look:
Your microservices
When you’re creating a new service, make sure you’re doing so from a template that ensures your Dockerfile, CI/CD pipeline, health checks, etc. are all the same. Your template is essentially a sample service that has all of your standards baked into it, so when a developer needs to stand up a new service they can use that as a baseline to clone and get started immediately. Read more about how Cortex can help you create microservices templates.
Your tools and metrics
Sure, it can be nice to let everyone choose their own tools. But when it comes to whether you use Postgres vs. MySQL, New Relic vs. Datadog, or deploy on Kubernetes vs. the raw service instance, mismatches in tooling can end up creating a big headache. Find opportunities, especially when your org is still small, to pick one tool and stick with it. This means assessing your tools rigorously to make sure that they support all the use cases you need now and in the future.
Your naming conventions
This seems small, but it’s so important. Every engineering team has a horror story about missing some essential reporting because it was coming in under an unexpected name—”response_time” instead of “latency,” for example. And when Slack channels aren’t given standard names, it can be impossible to figure out who you’re supposed to ping with an urgent question.
Naming tends to diverge as your team grows and goes remote, so it’s good to create contentions early on. One thing to watch out for: engineers love naming things after references to their favorite movies or TV shows. Problem is, not everyone is going to get that reference. Instead, use descriptive names like “the payments service.” You’ll be more inclusive to everyone on the team, and other engineers will instantly know what your service does.
Your documentation
Do you know where to find a given resource when you need it? This is one of the top things that can waste time as an engineer. One team might store write-ups in Google Docs, another team uses their own wiki, and yet another has created markdown files. And even worse is when concepts aren’t documented at all. Oftentimes, when someone leaves the team, they take their knowledge with them. Make sure you don’t run into these issues by enforcing consistency around what’s documented and where that document lives.
Standardization = visibility
When you focus on consistency within your engineering org, engineering leaders get visibility. For instance, if your naming conventions and tooling are standardized, it’s easy to aggregate your team’s work into one central report for leadership. Answering questions like “what is our uptime like across all our services” could be very difficult otherwise. In turn, visibility helps your team make better investments and more informed decisions.
Whether it’s service Scorecards, our Service Catalog, or microservices templates with CookieCutter, Cortex is the one place where you can standardize everything from your documentation, to your ownership and governance, to your on-call practices. Check out cortex.io to learn more about our product.
