TL;DR

Modern Apps use Platforms, Continuous Delivery, and Modern Languages.

Or more specifically, Modern Apps are written in Modern Languages, get deployed onto Platforms, and that deployment process is Continuous Delivery (as these things are all interconnected).

Background

‘Modern Apps’ seems to be a hot topic right now. Some of my DXC colleagues are getting together for a workshop on Modern Apps next week (and this will be pre-read material). Our partner VMware launched its Modern Applications Platform Business Unit (MAPBU) this week, which brings together its acquisitions of Heptio and Pivotal. But it seems that many people aren’t too clear about what a Modern App actually is – hence this post.

Modern Apps use Platforms

Modern Apps are packaged to run on platforms; and the packaging piece is very important – it expresses a way by which the application and its dependencies are brought together, and it expresses a way by which the application and its dependencies can be updated over time to deal with functional improvements, security vulnerabilities etc.

It seems that the industry has settled on two directions for platforms – cloud provider native (and/)or Kubernetes:

Cloud Provider Native

‘Cloud Native’ is a term that’s become overloaded (thanks to the Cloud Native Compute Foundation [CNCF] – home of Kubernetes and its many members); so in this case I’m adding ‘Provider'[0] to mean the services that are native to public cloud providers – AWS, Azure, GCP.

And mostly not just running VMs as part of the Infrastructure as a Service (IaaS). For sure it’s possible to build a platform on top of IaaS (hello Netflix and Elastic Beanstalk etc.).

And not just the compute services, but also the state management services, whether that’s for more traditional relational databases, or more modern ‘NoSQL’ approaches whether that means key-value stores, document or graph databases, or something else.

The use of cloud native also implies that apps are composed from a set of loosely coupled services that connect together through their Application Programmer Interfaces (APIs). In general we can also expect an app (or group of apps working on the same data) to run on a single cloud provider, because of the economics of data gravity.

Kubernetes

In just over 5 years since its launch at the first DockerCon it seems safe now to say that Kubernetes has won out over the panoply of other platforms. Mesos, Docker Swarm and Cloud Foundry all took their swing but didn’t quite land their punch.

There’s definitely some overlap between Kubernetes and Cloud Native as defined above (particularly in Google’s cloud, where arguable they’ve been using Kubernetes as an open source weapon against AWS’s dominance in VM based IaaS). But in general it seems people choose Kubernetes (rather than cloud native) for its portability and a sense that portability helps avoid lock in[1].

Portability means that something packaged up to run on Kubernetes can run in any cloud, but it can also run on premises. For those who determine that they can’t use public cloud (for whatever reasons) Kubernetes is the way that they get the cloudiest experience possible without actual cloud.

There’s a lot of scope for internal platform engineering teams to get themselves into trouble building something out of Kubernetes (which is addressed very well by Forrest Brazeal in his ‘Code-wise, cloud-foolish‘ post), but I’m expecting VMware (with Tanzu) and Google (with Anthos)[2] to take care of that stuff so that enterprises don’t have to.

Modern Apps use Continuous Delivery

Or maybe even Continuous Deployment, but mostly Continuous Delivery (CD), because not many organisations aren’t ready yet to have code changes flow all the way into production without at least one manual step.

CD pipelines provide a connective tissue between ever changing user need, and the platforms that apps are deployed onto.

CD pipelines also embody the tests necessary to validate that an application is ready for a production environment. For that reason Modern Apps are likely to be written using techniques such as Test-driven Development (TDD) and Behaviour-driven Development (BDD).

Of course there will be times where the test suite is passed and things make their way into production that shouldn’t, which is a good reason to make use of Progressive Delivery techniques and Observability.

Continuous Delivery implies DevOps

Pipelines run across the traditional Dev:Ops lines within an organisation, so running Modern Apps mean going through organisational change. DevOps Topologies does a great job of illustrating that patterns that work (and the anti-patterns that don’t).

It’s no accident that the operational practices of Site Reliability Engineering (SRE) evolved within Google at the same time as they were building and moving to their Borg Platform.

Modern Apps use Modern Languages

Or at least modern frameworks for some of the older languages – there’s a whole ton of Java still being written, but there’s a world of difference between the Enterprise JavaBean (EJB) centric world of Java 2 Enterprise Edition (J2EE) and today’s Spring Boot apps.

The RedMonk Programming Language Rankings (June 2019 edn) provide a good guide, if you can ignore C++, C and Objective-C, as popularity doesn’t equate to modernity. There’s also the Programming languages InfoQ Trends Report (October 2019 edn), which charts languages on a maturity curve:

and might be polyglot

Monolithic apps imply a single language; but the rise of microservices architecture comes about in part by empowering developers to choose the right languages and frameworks for their piece of the overall puzzle.

but doesn’t have to use a Microservice architecture

‘Microservices are for scaling your engineering organisation, not your app’ is how Microservices pioneer Adrian Cockcroft puts it, which is one of the reasons why Microservices is not a defining feature of Modern Apps.

It’s perfectly OK to have a small monolith developed by a small team if that’s all it takes to satisfy the business need. Per John Gall:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.

---

A service provider view

Most of the discussion on apps centres on in house development, and the notion of ‘you wrote it, you run it’ is central to the operations philosophy within many organisations.

But looking at the application portfolio of most DXC customers there’s typically very few in house applications (and hence not very much ‘you wrote it, you run it’).

For sure there’s a bunch of apps that service providers like DXC (and Luxoft) and our competitors build (and run); but there’s also a ton of packaged apps (aka commercial off-the-shelf – COTS) that we run the infrastructure for.

There’s been a general shift away from on premises packaged apps to SaaS for CRM (e.g. Siebel to Salesforce), HR (e.g. Peoplesoft to Workday) etc. But there are still the cloud refusniks, and there are still many Independent Software Vendors (ISVs) selling stuff into the mass market and down to various niches. Just as virtualisation drove a shift from scripted installers to virtual appliances, we can expect to see another shift towards packaging for Kubernetes.

As we look forward to a world more defined by Application Intimacy, the work of service providers will be less about running the infrastructure (which is subsumed by the platforms), and more about care and feeding of the apps running on those platforms.

---

Bonus content

Platform History

Both Cloud Foundry and Kubernetes trace their roots back to Google and its Borg platform.

Cloud Foundry came from Xooglers Derek Collison and Mark Lucovsky during their time at VMware (before it was spun off into Pivotal), and the BOSH tool at its heart is a homage to Borg (BOSH == borg++).

Meanwhile Kubernetes came from within Google as a way of taking a Borg like approach to resource management applied to Linux containers that had been popularised and made accessible by Docker (which built on the work the Googlers had put into the Linux kernel as cGroups, Kernel capabilities and Namespaces on the way to making Linux and Borg what they needed).

It’s therefore well worth watching John Wilkes’ ‘Cluster Management at Google‘ as he explains how they manage their own platform, which gives insight into the platforms now available to the rest of us.

Of course platforms existed long before Borg, and the High Performance Computing (HPC) world was using things like the Message Passing Interface (MPI) prior to the advent of commercial grid computing middleware. What changed in the last decade or so has been the ability to mix compute intensive workload with general purpose (typically more memory intensive) workload on the same platform.

Heroku deserves a mention here, as one of the early popular Platforms as a Service (PaaS). The simplicity of its developer experience (DX) has proven to be an inspiration for much that’s happened with platforms since.

12 Factor

Modern Apps probably should be Twelve-Factor Apps:

1. Codebase One codebase tracked in revision control, many deploys
2. Dependencies Explicitly declare and isolate dependencies
3. Config Store config in the environment
4. Backing services Treat backing services as attached resources
5. Build, release, run Strictly separate build and run stages
6. Processes Execute the app as one or more stateless processes
7. Port binding Export services via port binding
8. Concurrency Scale out via the process model
9. Disposability Maximize robustness with fast startup and graceful shutdown
10. Dev/prod parity Keep development, staging, and production as similar as possible
11. Logs Treat logs as event streams
12. Admin processes Run admin/management tasks as one-off processes

But let’s just acknowledge that the 12 Factors might be aspirational rather than mandatory for many Modern Apps in real world usage.

HTTP or messaging based?

The web has made the HyperText Transfer Protocol (HTTP), and its more secure version HTTPS ubiquitous, especially as most firewalls have been configured to allow the easy passage of HTTP(S).

But HTTP is synchronous, and unreliable, which makes it a terrible way of joining things together.

Developers now have a bunch of choices for asynchronous (and sometimes reliable) messaging with protocols like AMQP, MQTT, NATS[3] and implementations such as RabbitMQ and Apache Kafka.

REST

The uphill battle here for messaging is that in the wake of heavy weight Service Oriented Architecture (SOA) defined by protocols like SOAP and WSDL, respresentational state transfer (REST) became the de-facto way of describing the APIs that connect things together, and it’s very tightly bound to HTTP methods.

---

Notes

[0] Thanks to my colleague Eric Moore for providing the suggestion of ‘Cloud Provider Native’ as a better label than just ‘Cloud Native’ (see thread on LinkedIn for background).
[1] Some wise words on this topic from OpenStack pioneer Randy Bias ‘You Are Locked In … Deal With It!‘ and from Gregor Hohpe on Martin Fowler’s blog ‘Don’t get locked up into avoiding lock-in‘ that now seem to have found their way into UK government guidance – ‘Managing technical lock-in in the cloud‘
[2] See Kubernetes and the 3 stage tech maturity model for more background
[3] Derek Collison pops up here again, as NATS came from his efforts at Apcera to build a better enterprise PaaS than Cloud Foundry. Collison has deep experience in the messaging space, having worked on TIBCO Rendevous and later their Enterprise Message Service (EMS), which he reflects on along with the origins of Cloud Foundry in this Twitter thread.