So, you’re thinking about doing a full rewrite of an application. You’re faced with an infinite number of choices, and the decision feels overwhelming.
The good news is that it’s not the end of the world.
I’ve always been a do-it-yourself kind of person. If my faucet is leaking, I repack the nylon packing. If a valve spring breaks on my vehicle, I replace it. If my family wants a new outdoor living space, I build a deck. I’ve carried this mentality throughout my life and into my professional career as a web application developer.
web application developer: (noun) a person who is supposed to know how to do everything from creating reusable, mobile friendly CSS frameworks to developing scalable and secure APIs.
This definition is more accurate in small companies where team members wear many hats and where silos don’t exist.
The Monolithic Challenge
Recently I was tasked with examining what it would take to get one of our monolithic web applications ready for “the big time.” What is a monolithic web app? Well, at scale it can be a big hairy mess of a Swiss Army knife. In our case, it was a PHP application written in the Laravel framework consisting of ~200,000 lines of code to power the display, interactivity, API, business logic, translations, data models, data structure, etc. With an app of this size, web app developers experience more challenges with running continuous integration, knowing the impact of changing code, and getting a new developer ramped up to be able to contribute to the code base, among many others.
Now, I love PHP and am a proponent of using the right tool for the job. In a lot of my projects, PHP is a great fit. Can I serve up a dynamic website, you ask? No problem. I have an easy way to write, fast, forgiving web server language right here in my toolbox.
However, I was asked to create a large SaaS (Software as a Service — think of Salesforce) product and have it scale to hundreds of thousands of concurrent users. I soon realized that if we used PHP, the cloud compute power needed to handle the load would become exponentially more expensive. Running a large-scale PHP app is extremely resource heavy, which translates directly to $$$.
Making the Action Plan and Selecting Tools for Rewriting
Faced with the decision on the next evolution of the app, I quickly knew that we needed to move toward a more modern architecture. It had become critical to separate the front end from the backend logic that wires up all of the services needed to run the app. Additionally, I wanted to be able to sell usage of our API to allow others to consume the raw data that powers the app.
The result of all this is that we are going to write part of our web app in Go. Go (Golang) was created almost nine years ago as Google’s solution to modernizing a low-level language (mainly C). A low-level language is one that gets very close to the language that the machine executing it runs. This means that the machine needs to do very little interpretation to execute the code, making it extremely fast. PHP is 24 years old and has great community support because it’s an open source language (and so is Go). However, PHP is an interpreted language, meaning that when it is executed the PHP binaries read code and interpret it into something usable. The best PHP against the worst Go will never win the race.
Our plan includes breaking down our monolithic app into an SPA (single page application – a website/application that does not refresh the page and behaves more like a desktop app, think GMail inbox, when you select an email to read the page does not refresh it simply shows the email). The SPA will consume data from a service, namely our new Go API, which will also connect to many other microservices on behalf of the SPA to help streamline our effort. Creating the SPA will require a complete rewrite as well.
Adding Value by Rewriting Code
Is this worth it, you ask? YES. The amount of effort would only increase if we waited, and the opportunity to build it now will save us from some very expensive and embarrassing outages that are inevitable if we continue on with the PHP app that we have currently. If we did nothing, the only thing that would help would be throwing more resources at it (more memory, more compute power — think bigger and better computers), but this would increase the monthly expenditure dramatically. So, spending money now on development will save a whole lot of money later.
One positive side effect of breaking down the back end into several services and microservices is maintainability. Maintenance is a huge time-suck in the development world. Think of it this way: If you build a car as fast as you can and sell a lot of them at a low price, you will be very profitable… in the beginning. But, as time rolls on, you will sink money into warranty repairs to fix all the corners that you cut in initial quality.
I want our developers writing new and valuable code, not spending their time fixing errors that were made six months ago to meet a deadline. If we break up the code into smaller INDEPENDENT pieces (microservices), it will be easy to walk into a piece, find the error, correct it, release a small fix that doesn’t affect the rest of the app, and move on. Viola! Simple, continuous integration achieved. Consumers of these web apps also want that. They want to wake up in the morning, go to work, open up their chosen tools, and all of a sudden the tools are better and faster than the day before.
Another advantage for our business is that if we break the code into microservices, all our other products can use them, and we have to maintain only one set of code.
I hope this explanation has been helpful to you as you look at taking the dive into a full rewrite. Go is one of many great choices in writing a fast and maintainable API service-based backend. I chose it because we are going to use Google Cloud Products to host our code, and Go will play nicely with all the offerings.
Besides… let’s face it, I’m a Google fan boy, too.
We’d love to talk with you about your application development needs; Contact Us.