Part One: Building a Better Foundation
Often you will go and ask someone, “Hey, what stack do you use?”. They will answer something along the lines of “we use JBoss, Java 8, Spring, Hibernate, Oracle, and we have a React Frontend”. This is great, but it is missing an even more important part of the stack that gets overlooked. These things are:
- The methods you use to write, build, test, and deploy software
- The processes you use to effectively design the application you want built
- The infrastructure that you deploy your applications upon
When companies are small and the product base is small, these issues aren’t usually a problem — in fact, you will prototype and test different approaches a lot. When you grow to an enterprise level, however, updating software practices, changing business processes, and changing infrastructure can be incredibly risky and painful.
This is not a new problem, and many trends have come along over the past few decades to try and tackle this issue. Languages and frameworks were created to make building software easier, and continuous integration tools helped to test those builds. Frameworks like UML were designed to better capture the vision of what the final application should look like. Distributed computing allowed teams to break up batches of applications and put them on different servers, and SOAP services made it easier for these applications to communicate.
Despite all of this, the challenge of updating these legacy applications is still there. We do, however, now understand better some of the problems that are holding us back. Large monolithic applications are hard to update simply because of how complex they are — fixing one part of them usually has impacts on lots of other parts. A lot of software is written in long development cycles with lots of features being released together. Infrastructure is often managed by teams isolated from the teams building the applications that run on them.
To fix the complexity issue, software teams have started developing smaller components that work in isolation and are easily testable. These microservices also have the advantage that they can be scaled up independently as load increases — heavily-used services can be given more resources than lightly-used services. With monolithic applications, you need more servers to scale up, and the servers are generally under-utilized because you prepare for peak loads even when the loads are generally much lower. Microservices allow you to run with fewer servers that are better utilized, giving their resources to the tasks that need it most.
For the processes side, the teams are moving away from the traditional Waterfall approach and moving towards Agile. This can be a hard transition for some companies that have built business processes around the long waterfall process, but the benefits of Agile far outweigh the costs. With Agile, teams break large requirements into small chunks that can be delivered quickly, usually in under two weeks.
This also helps the business focus on what the most important requirements are, rather than listing them all up front. All software teams know that requirements change and that this can cause great disruptions in productivity. Agile allows teams to “fail fast”, which basically means that if the project isn’t going in the right direction, the team can change that direction almost immediately, rather than waiting until the end of a long waterfall cycle.
As for infrastructure, developers have begun using container technologies that effectively lets them manage their applications themselves. Developers now have the ability to launch applications in just days instead of weeks or months. Containers have made it possible to eliminate the need for servers dedicated to running just one type of application and instead run lots of containers with many different requirements and configurations.
Developers are happier because they can easily write, build, test and deploy software. They can quickly build a stack by creating simple manifest files that describe the infrastructure they need. DevOps and operations staff are happier because they didn’t have to tailor servers to the specific needs of each team. They also no longer have to do as much manual work to provision individual applications each time — instead they just give a team a quota of resources and let them manage it themselves.
These fundamental pieces are the first layer in the stack when I think of the perfect stack. It is much easier to build software when you are working on small well understood chunks rather than large complex units. Development teams are now able to demonstrate progress to their business partners more frequently, and this allows those partners to make adjustments to what they want along the way. Teams can now spend less time waiting for resources to be allocated and provisioned and spend more time doing what they love: building software applications.
In this first part of this series, I talked about some of the pieces that have become a fundamental part of building a great software stack. Microservices will allow your teams to write, build, test and deploy functionality much faster and utilize your existing infrastructure better. Changing your processes to Agile will accelerate your teams as you deliver features more quickly and deliver on the most important ones first. Moving to container platforms will enable developers to configure and launch their applications without involving operations staff.
These aren’t necessarily easy steps, and many enterprise companies have tried without success to adopt these methods. I have talked about some of these issues in other articles, but in a future article I will tackle the challenge of migrating monolithic applications to microservices, because it is most definitely doable.
In the next article of this series, I will talk about your API backend layer.