These days, it doesn’t matter if you’re a non-technical founder or a full stack developer, you’d have to be living under a rock not to have been exposed to messages about the cloud and modernizing application development.  “Get apps built fast!” and iterate rapidly to keep up with the ever-evolving landscape of user needs.

However, with the deluge of information that exists on the topic, it might be hard to “see the forest through the trees” when it comes to the elements that comprise a modern approach.

I think it’s a good idea to level set, or agree upon, what is meant by the term “modern application development.”

There are five (5) elements that make up a modern approach to app dev:
(1) Microservices

Many companies start their business with (what’s defined as) a monolithic application because it’s the fastest way to go to market. The problem with this approach, however, is that if any one process experiences a spike in demand, the entire architecture is stressed and has to be scaled up to handle the load of that one process.

Source: Red Hat

By contrast, microservices (as defined by Red Hat) are an architectural approach to building applications that are distributed and loosely coupled, so one team’s changes won’t break the entire app.  Services are built to serve specific business functions, like a shopping cart.

These services are run independently and can be updated to meet any demand scenario. Development teams are able to rapidly build new components of apps to meet changing business needs.

(2) Purpose-built databases

As Werner Vogels, CTO and VP of Amazon.comsaid: “Seldom can one database fit the needs of multiple distinct use cases. The days of the one-size-fits-all monolithic database are behind us, and developers are now building highly distributed applications using a multitude of purpose-built databases

Instead of a single database, modern applications are built with decoupled data stores in which there is a one-to-one mapping of database and microservice.  It is no longer a sound recommendation to have a single database act as a single point of failure – instead, choose the database that best fits the needs of the application.
(3) Serverless

According to Serverless Stack, “serverless is an execution model where the cloud provider (like AWS or Azure) is responsible for executing a piece of code by dynamically allocating the resources. And only charging for the amount of resources used to run the code. The code is typically run inside stateless containers that can be triggered by a variety of events including http requests, database events, queuing services, monitoring alerts, file uploads, scheduled events (cron jobs), etc. The code that is sent to the cloud provider for execution is usually in the form of a function.”

AWS introduced the concept of serverless in 2014 with the launch of AWS Lambda, a service that lets companies run code without provisioning or managing servers. Going serverless frees companies to focus on activities that differentiate, like product innovation, instead of the endless (and often expensive) task of managing physical hardware.
(4) Automated release pipelines

Continuous integration (CI) and continuous delivery (CD) embody a culture and collection of practices that enable modern application development teams to deliver code more frequently and reliably. The implementation is commonly referred to as “CI/CD” or “CI/CD pipeline”.
Source: Synopsis
CI/CD is one of the best practices for a devops team to implement that enables teams to focus on meeting business requirements, code quality, and security because deployment steps are automated.
(5) Continuous security

According to Werner Vogels, CTO and VP of Amazon.com in this post, “In the past, many companies treated security as if it were magic dust—something to sprinkle on an application after it was ready for release. This doesn’t work well in a continuous release cycle, so organizations had to take a new approach to security, building firewalls around the entire application. But this also introduced challenges. The same security settings were applied to every piece of the application, which is problematic if an application is built with independent microservices that may need different settings.”

“For this reason, in modern applications, security features are built into every component of the application and automatically tested and deployed with each release. This means that security is no longer the sole responsibility of the security team. Rather, it is deeply integrated into every stage of the development lifecycle. Engineering, operations, and compliance teams all have a role to play.”

The role of DevOps isn’t just about development and operations any longer.  IT security must also play an integrated role in the full life cycle of your apps.  As a result, the term “DevSecOps” has emerged to mean planning for application and infrastructure security from the start.

So, do you need ALL of these in order to be considered modern?  No. 

To us, it’s all about evolution – it can take time and intentional steps to adapt. 

But adapt you must.