Standardizing your web application stack and how to do it

Managing web applications from the ground up can be a daunting task. One application alone can quickly grow in complexity, let alone the multiple applications that are often required by different business units and stakeholders growing simultaneously. Add the ever-changing landscape of trendy frameworks and runtimes, and you quickly find yourself with an unmanageable mess of different technologies. 

Standardizing your application stack can help reduce the clutter. Allowing you to get started quicker and specialize in supporting a few technologies really well while keeping tabs on the evolution of the technological landscape. 

The obvious danger of defining your own standards is succinctly illustrated in this xkcd strip. So let’s put a more nuanced spin on things right away: any standards you establish won’t necessarily define the best practices, nor do they need to. Determining good enough practices already ensures that work is, “performed in accordance with codified professional practices”, as argued by J.W. Moore in An integrated collection of software engineering standards.

That’s not to say standards will miraculously solve all your problems. Defining them is a grind, abiding by them can be inconvenient, but not having them is worse in the long run. Ideally, the right standards, if used correctly, will have a measurable economic impact in an organization.

So many apps, so little time

According to Okta’s 2023 Businesses at Work report, companies use 89 different applications on average—with this number exceeding 200 for larger organizations. While a lot of these applications are likely to be Softwares-as-a-Service (SaaS) or applications you don’t actively develop, each of them needs to be managed in some way, even if it’s just at an administrative level. 

Focusing just on the digital experiences you are actively developing and delivering to your customers, there is even more to consider. Changing requirements and increased traffic may mean that what started as a single monolithic application responsible for handling both business logic and marketing website content will at some point need to be split into multiple standalone deployments. 

What used to be a single codebase deployment is now a marketing site with landing pages, a blog, the core application (a SaaS offering or maybe an e-commerce site), and different tools to support that. Tools which could include anything from internal tools that you are building to improve customer support processes, data crunching, inventory management, and the list goes on.

Delivering applications comes with an accompanying set of challenges that you and your team will be all too familiar with: security (infrastructure and dependencies), availability and reliability, performance, scalability, and monitoring. All of these fields are constantly evolving and security priorities alone are shifting fast.

Add these to each application and service you are running—which each might come with their own respective stack—and development happening in a silo and soon keeping track of things becomes increasingly difficult. Yes, there’ll likely be some alignment inside the company in terms of preferring, say, PHP over Java, but even then there is a lot of potential for divergence—and differing opinions.

Standardize where it matters

So what can you do to avoid shadow operations? The operations in which different departments, business units, teams go and build their own stack using whatever framework they landed on at that time, spin up their own infrastructure to support it, and silo-off all the knowledge around how it runs, leaving your team with an app no one understands when someone inevitably leaves. Sound familiar? 

Part of the answer is standardizing the components you build your applications from. Standardization can come in different forms. What matters is to define where you can achieve gains by dropping the things that cost time and energy that is better spent elsewhere. That can mean dropping infrastructure management and ops by going the PaaS route to focus on the app.

But you can reduce complexity even further than that. At the core, standardization is about keeping a handle on the different components that make up any of the applications you need to run your business as efficiently as possible. In many cases, that will mean deciding on a set of technologies that you can use to build the majority of the things you need—this will also reduce ops if you’re building on top of IaaS in a DIY manner.

Doing so helps to get everyone on the same page by providing training, maintaining internal documentation, and facilitating switches between teams and departments without having to re-onboard everyone from scratch. As well as generally reducing knowledge silos. This is part of the challenges platform engineering and internal developer platforms aim to solve.

It’s also not about being stuck with PHP/Python/Javascript forever. Standardizing doesn’t mean picking five pieces of technology and never being allowed to use anything else. Rather, it’s implementing a process that will help you identify the types of services and runtimes you will build up knowledge in and that can in turn become your go-to technology whenever you need to start a new project. Implicitly, you might even have some of this already, so it’s really more about formalizing things and making them explicit and documented. 

Giving this some serious consideration will allow you to deal with less decision paralysis and instead focus on getting started with a project. If during your initial discovery, you notice there are specific requirements that mean that this project will benefit from doing something differently, that doesn’t mean you can’t do that. It means deviating from the norm will be the exception rather than the default—and it’s likely your team will have thought about the consequences of that decision in more detail before doing it.

Keeping your options open

One danger of standardizing too much as touched upon above is that you risk losing flexibility and locking yourself into technology choices for years to come. In a rapidly changing environment such as tech, the risk of losing touch with technological advancements is real. To avoid a form of dogmatism that would force your hand even when it might not make sense, think about it in a more holistic way rather than in actual frameworks or programming languages.

This is why I would argue that it’s important to make this more of a process that can evolve. A process that incorporates routinely reevaluating choices to keep up to date without jumping on technologies that might not even be supported in two years (which is something you definitely do not want for any kind of business-critical application). There is a reason that, while sometimes maligned, certain frameworks stick around longer than others.

So rather than saying, “From now on we’re going to do everything using programming language X and database service Y.” It’s more useful to assess a select few that will become part of your core set of tools. One way to go about such an assessment is to consider the strengths and weaknesses of different technologies. Acknowledging that there is no one-size-fits-all solution. With that in mind, you could ask yourself the following questions:

• What has the evolution of programming languages been in the past 10 years? Which ones have remained stable, which ones have faded into obscurity, and which are the relative newcomers? Stack Overflow, GitHub, and many others would be good sources for researching such trends.
• What types of services (databases, caches, message queues, etc) do you usually need for the projects you are building? How is interoperability between the services you are considering and the frameworks you might be using? For example, Postgresql is the preferred database to use with Django, so if the main application you are building is using that, you might want to consider using Postgres for the Drupal CMS you are using to build your corporate site to avoid having to account for the differences between those two systems.
• What kind of expertise do you already have in your team? If you have a set of experienced PHP developers, it’s unlikely that you will completely forgo that knowledge and just start doing everything in Go. Additionally, how well are you able to hire for the required skill set? 

A design system for your tech stack

It is generally accepted that digital product design will make use of a design system to provide components that can be reused and assembled to build new things while adhering to standards such as visual and brand identity, messaging, and more.

The same rationale should also apply to your tech stack. If a design system contributes to streamlining workflow, creating a unified language between cross-functional teams, improving maintenance and scalability, and allowing stronger focus through tackling common problems, isn’t this something we also want for our tech stack?

Having a more standardized approach to infrastructure will help you to think about problems from a different perspective, helping you to focus on your app first, rather than on the infrastructure, because most of those decisions will already have been made.

The introduction of such a system can be incremental, start with making decisions about what you want, then start working towards implementing changes in a standardized manner. With time, every new piece you add or change will be covered by the system you’ve put in place—similar to Martin Fowler’s strangler fig pattern for application rewrites.

A PaaS approach

At Platform.sh, we approach thinking about tech stacks in a similar manner: developers get a set of bricks (managed runtimes and services) that they can use to build their applications and evolve them over time. The available runtimes cover the majority of the most popular programming languages, allowing flexibility when it comes to starting a new project. 

Managed services provide access to the most well-known, industry-standard databases, and caches, and help to reduce the learning curve with sane defaults used as a standard.

Similarly, by abstracting away the operating system and complexity of the networking layer, it ensures that there’s no debate on what flavor of Linux to use and that all tooling is compatible with it.

Going back to the earlier point about having a design system for your tech stack—templatizing your applications with Infrastructure-as-Code (IaC) makes it possible to define a starting point for projects that uses technologies you have mandated for certain types of projects with zero cognitive overhead for your developers since this work has already been done and can be reused at will.

On Platform.sh, your entire application is defined by the contents of the Git repository it lives in. This includes the code that you write and maintain but also the services it relies on and the steps required to build and deploy it. 

This means that once you have decided on the basic tech stack for certain types of applications, you can have that stack pre-configured in a Git repository that only needs to be forked to start deploying and developing a new project. As your application evolves, you can adjust and add new runtimes or services as required—all while building new features that leverage these underlying technologies. By doing so you are effectively composing your infrastructure by defining the type of service you need and the resources it should be allocated.

The case for stack standardization

Finding the correct technology to use is always a very individual matter where many factors come into play, ranging from the expertise you already have, the sort of developers you might be looking to/can hire, and maybe also certain requirements you have little control over.

It is also important not to lock yourself into technologies for the sake of doing so, either because that’s the way it’s always been done or for fear of missing the boat on the latest trending technology that everyone seems to be using.

Rather, establishing a process that enables you to make informed decisions while avoiding becoming overwhelmed by choice is the first step to standardizing your web application stack. Conducting an assessment of what’s on the market as well as realistically gauging your own capabilities will go a long way towards informing the choices you’ll make.

Reducing choice doesn’t mean being locked into one single piece of tech that you can never get away from. But if you can only pick between three database technologies you will be much quicker to weigh the pros and cons of each (based on your project’s requirements) than if you were to do the same comparison between 15 of them.

Applying some form of standardization will help reduce cognitive overhead, allowing you to make decisions faster, reduce fragmentation of knowledge and expertise within your organization, and make it simpler to keep tabs on the kind of things you are running on a day-to-day basis.