Technology moves incredibly quickly — and it's difficult to know how to keep up. Particularly for large companies that have seen success over the last decade, there seems to be a sustained pressure to be constantly evaluating new technologies and attempting to introduce them in order to stay competitive. This pressure is often overpowered by fear of short-term risk, bureaucratic barriers that make it daunting to introduce a new tool, or a lot of times simply because it never feels like the "right time".
While modernization initiatives often don't land in the "urgent" quadrant, it's incredibly important for a company to develop a comprehensive strategy towards it. Here at Cortex, we've helped a fair share of enterprises do just this. In the post below, we offer a set of best practices we've collected and some supporting guidelines for your team as you develop a modernization strategy.
What we mean by modernization
First, let's define what we mean — and DON'T mean — by modernization. At Cortex, we've developed strong conviction that modernization means two things:
Evaluating and adopting new technologies with architectural promise and proven solutions.
Defining and adopting best practices that enable the adoption of new tools at scale.
The second point here is key. Modernization does not necessarily mean adopting shiny new technologies - it also means adopting modern software development best practices beyond tooling. Per this definition, modernization can look like any of the following:
Encouraging security-first development and hiring a DevSecOps function.
Adopting a standard platform, such as Kubernetes.
Moving to a supported version of Java or Python.
Migrating massive Cron jobs to modern data orchestration tools.
Driving ownership and accountability across your microservices.
Automating manual testing and code pushes with a CI/CD process.
While these may be popular examples, they are by no means prescriptive. What modernization needs to deliver for your team is most important, and that can take a variety of forms.
Why modernization is important
If done right, modernization comes with a plethora of benefits. To list a few:
Talent. If you use modern tooling and best practices, you're more likely to attract a strong pool of candidates and retain star players on your team. People don't want to spend time on problems that have been solved by a third-party tool, and they want to continue sharpening their skills to stay competitive in the job market. They also want to know that your product is future-proof.
Productivity. There's a lot of tedious, manual work that comes with maintaining an aging tech stack. It might not be broken, but it's likely costing your team precious hours that could be spent innovating and solving problems for the future.
Security. If you fall behind on the versions of tools in your stack, you're more vulnerable to security risks and lack of support from vendors.
Cost. New tools might be expensive to adopt and migrate to in the short-term, but investing for the long-term is likely to save you that cost many times over.
Where to Start
For teams committed to taking on modernization initiatives, it can be hard to know where to start. We'd encourage your team to start with two critical questions:
First, take an audit of where you stand today. What challenges is your team facing that you'd like to invest in solving? What are people spending the most time on? What kind of work do your software engineers complain about? What pressures are you getting from the rest of the company?
Then, ask yourself what you want to optimize for. Once you have a strong understanding of where your team stands, you can start to pin point in which direction you want to optimize. Do you want to be able to deploy microservices faster? Do you want to consolidate services into a single platform you can operate and manage more easily? Do you want to optimize on quality and unit tests or CI? Are you trying to move faster because of competition?
All of these answers are fair, but they're specific to your team and should guide the approach you ultimately end up taking. There’s no one-size fits all strategy for modernization. Engineering leaders should understand their specific goals before embarking on this journey.
Try service standardization
A tenet of modernization that we at Cortex find critical is standardization. As we've said:
"Establishing consistency in the way microservices are built can [...] help you massively improve developer velocity, reduce operational overhead and minimize the complexity of your platform."
If you use Cortex, you'll find service templates to be a powerful feature towards this effort. With service templates, you can create a templated version of boilerplate code (e.g. test files, CI/CD scripts, project scaffolding) that you can then reuse to create a new microservice. To use a template, run a single command generates boilerplate code for you.
We care deeply about helping our customers find success in modern tooling, and we've found that standardizing the creation of a new service significantly lowers maintenance burden and makes it easier for your team to scale.
How to know when you get there
We like to say that modernization is a mindset more than it is a black-and-white goal. If you're not sure where you stand, think through some of the following questions as litmus tests:
When candidates ask you about our tech stack and say they're excited to work with your team because of the technology you use, that's a good sign.
You have a process for evaluating new tools and you empower engineers to carry out proof-of-concepts.
You've reduced the cost of maintenance over time.
The tools you use are closely integrated and drive up developer productivity.
You have a culture of curiosity and innovation.
You've simplified or consolidated multiple services into a single platform or otherwise central place.
Modernization can look different across different teams, and we're here to help you get there. If you're interested in continuing the conversation, book a demo or send us a note at team@getcortexapp.com.
