Building Better Software in the Age of the Cloud, Microservices, and DevOps

DZone 's Guide to

Building Better Software in the Age of the Cloud, Microservices, and DevOps

Cloud, microservices, and DevOps form the trinity technological advance that make software development efficient in the modern age.

· DevOps Zone ·
Free Resource

Let’s face it: software runs the world. In fact, you’re probably reading this article on a computer right now, or your smartphone – maybe through an app or your Internet browser. Even if you printed it out (please, don’t admit you did), just getting access to this text required software. You should probably say, “Thank you, Internet. Thank you, web developers.” Everything we do today (well, except curling and kite flying, so maybe almost everything) is powered by software, from pumping gas to getting cash out of the ATM to using the microwave. And most of this software is connected to other systems, sometimes located thousands of miles away in an esoteric networking netherworld dubbed “the cloud.” All the software, from IoT to the website delivering this page, is connected in one big collective web of 1s and 0s. And although this software may employ many different languages and frameworks, it shares a lot of commonality in how it’s developed, especially software that runs over the Internet.

You probably already know that web applications share a pretty standard stack—operating system, web server, database, and execution environment. But you may also have noticed that not all software is developed with the same care. In fact, some of it is downright bad. Deplorable. Poorly designed, badly executed, and terribly managed.

Software shouldn’t have to fall into the “I-need-to-beat-my-head-against-the-wall-because-this-application-is-so-frustrating category.” Whether you’re a code monkey or an architect, building good software should be a priority for everyone in the industry. It doesn’t matter if you are in a 50-story high-rise working for “the man” or toiling away at your own startup, there are things that we can all do as developers to ensure the software we create and deliver is top notch.

Keep It Small

The first step in creating better software is to keep it small. I’m sure you’ve seen applications with thousands of lines of code. Tens of thousands. Maybe even hundreds of thousands? Software with a lot of lines is software with a lot of moving parts, making it nearly impossible for a single developer to get their intellectual arms around it. That’s why complex software should be broken down into small, discrete components that make the overall application easier to design, maintain, and manage.

Ultimately, it’s about reducing the development team’s cognitive load: reduce the timeframe that developers must consider when building a new feature. The shorter the time frame, the lower the cognitive load.

Next, reduce the size of the code. Less code means a lower cognitive load.

Finally, simplify the process for software changes. You guessed it—simpler process equals less cognitive load.

Make It Developer-Oriented

Building and launching software quickly is critical because being slow-to-market can kill adoption. A huge bottleneck to quick software development is often how much time the engineers spend focusing on the business logic of a feature. If they waste too much time on “figuring out how it’s supposed to work,” they spend less time programming. The key is to make the development process more “developer-oriented,” freeing your developers from distractions so they can focus on developing your software. To do this, the application ecosystem should encompass three things.

First, systems and processes need to be easy to work with. Development environments that require significant effort to get all the components up and running are barriers to productivity. For example, clone GitHub repos so developers don’t have to set everything up from scratch.

Second, ensure that architecture and code are easy to understand. Once the system is up and running, having a standard way to interface with application code is also critical. That means RESTful APIs which adhere to best practices like data in JSON format and CRUD operations that use HTTP verbs. For example, a microservice typically has the following characteristics: components and infrastructure are containerized (for instance, in Docker images), the APIs between services are RESTful, and their data is formatted in JSON. Furthermore, implementing application services as microservices, which are focused on a specific task, provides both a clear interaction model and a clear separation of concerns. Contrast this with monolithic development where engineers have access to all the layers of the application code—from APIs to data structures, methods/functions, and object related mapping (ORM) and/or data layers for data access. Without strict management of coding standards and data/function access, it is very easy for components to overlap and interfere with each other.

Finally, provide DevOps support for managing tooling. Bogging down engineers with the responsibility for system setup and operation (maintaining scripts, writing makefiles, and maintaining a CI/CD pipeline) is a surefire way to take them off task. As a more desirable alternative, having DevOps embedded with the engineering team means that there is a person or group dedicated to managing the more complex aspects of the development infrastructure.

Network It

As applications have become larger and more complex, they have, by nature, become more distributed. Remember that big, bad cloud? More application developers, especially those building on web technologies, are employing the cloud to ensure scalability, reliability, and availability. One of the historic concerns around networking, though, has been speed—accessing a component over a network is still an order of magnitude slower than accessing that same component in memory. However, modern data centers have high speed networking between virtual machines or containers which is infinitely faster than previous generations of networking. And networked applications are, by nature, more resilient. For example, with a load balancer like NGINX, you can monitor your services and ensure requests go to healthy instances. You can also easily scale up individual application components that are bottlenecks (using tools like Kubernetes), rather than the whole system as with a monolithic application. Finally, networked applications are easier to deploy, manage, and scale versus monolithic software. Monitoring tools like NGINX Controller provide quantified data about your services and the request loads moving among them.


Stop struggling to make better software. Follow these three simple principles—keep it small, make it developer-oriented, and network it. With these tenants driving your software development efforts, you can ensure the long-term viability of your application as well as the health and well-being of your development teams.

cloud, devops, microservice, microservice architecture, networking, software

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}