A Cloud Native Reference Application – InApps Technology 2022

It’s safe to say that the Cloud Native community is highly active and contains a diverse set of opinions and technologies. Anyone that wants to investigate a microservice architecture for their next application is met with an enormous array of options. There’s a choice of container runtimes, such as Docker, rkt and  _hyper; a choice of orchestration frameworks, such as Kubernetes, Swarm, Mesos and Nomad; a choice of networking layers such as Calico, Weave, and Contiv; and a choice of supporting services and frameworks such as Kong and GoKit.

Whilst the wealth of options means that there exists a solution to fit most situations, it also makes life difficult for newcomers, who can be left feeling bewildered and confused. Organizations can expect to spend significant effort evaluating potential solutions for maturity, efficiency and applicability to their use-case.

I’m using “Cloud Native” in a broad sense here, to mean anyone writing software in a modern fashion and making use of cloud platforms or technologies. This is intended to cover architectures such as microservices and 12-factor apps as well as technologies such as containers and dynamic orchestration platforms.

Taking a step back, it seems we’ve been here before. JavaScript has an equally diverse and active community; it seems a new framework is born and an old one dies every week (this blog coins the term YAFS — Yet Another Framework Syndrome — for the phenomenon). Back in the noughties, Java development was in a similar place — as well as J2EE there was JBoss, Spring and Oracle Application Server. In the case of both Java and Javascript, reference applications offered a useful tool for making comparisons between implementations and frameworks, allowing users to quickly grok the differences between platforms and make an informed decision.

In the world of JavaScript we have todomvc, which recreates a simple ToDo application in various JavaScript frameworks. This is a simple application which can be easily understood and fits into a small amount of code but contains enough complexity to highlight differences in style and expressivity. Several of the frameworks have multiple implementations using different libraries, integrations or compilers — for instance, the AngularJS example contains versions with Require.JS, TypeScript and Google Cloud Platform. Even outside of the core todomvc site, developers have ported the application to other languages for demonstration purposes e.g: Om and Swift.

For Java, we had the Pet Store, developed by Sun Microsystems as part of their blueprints series to epitomize an idiomatic JavaEE application using recommended best practices and patterns (as well as showing off the latest J2EE libraries). The application itself recreated an online store selling various kinds of exotic pets. The Pet Store is now completely out-of-date, but in its time it was a useful resource for getting started with J2EE and later became a touchstone for getting going with other frameworks; Spring, JBoss and .Net all used modified versions of the Pet Store as a familiar example to quickly onboard users.

Introducing Sock Shop

So what makes a good reference application? It needs to be small enough to be quickly understood and easily ported, but large enough to demonstrate various aspects of the technology and to give developers a feel for the framework and the programming style it promotes.

Hello World

Read More:   Looking at How to Look at Kubernetes – InApps Technology 2022

Hello World is the archetypal first step when learning a new language, and can be considered the granddaddy of all reference applications. The programming chrestomathy site Rosettacode.org goes one step further and uses small tasks (e.g creating a Sierpinski triangle) to enable comparison programming languages. Similarly, the Computer Language Benchmark Game, managed by Debian,uses toy programs for benchmark comparisons. However, the examples in both of these projects lack the depth required to model a real-life application and don’t always favor idiomatic code (benchmark code, in particular, will favor performance over best practice.)

It should emphasize best practices and use idiomatic code throughout. Whilst performance shouldn’t be ignored, it should not be the goal unless the point of the application is to form the basis of a performance benchmark. The application should lend itself towards reuse in a variety of contexts; ideally, it will be possible to contrast implementations using different platforms, design patterns, libraries, frameworks and architectural approaches whilst still maintaining a level of familiarity for the user.

However, with that in mind, care must be taken not to compare apples with oranges. For example, Microsoft seized on Pet Store as a way to show that C# was more performant that Java, but as the Java implementation was written with portability as opposed to efficiency in mind, it made for an unfair comparison.

Weaveworks, with the help of Container Solutions, has developed “Sock Shop,” a mock on-line store for purchasing socks (with holes). It has a clear lineage from the old Pet Store app, and even has some Java code here and there, but it is otherwise a completely different beast, designed as a cloud native application with containers and microservices at its core. The original mission of “Sock Shop” was to highlight the different deployment platforms supported by the Weave Net and Scope products, including Amazon ECS, Mesos and Kubernetes. This list is growing, with work in the pipeline for the new version of Docker Swarm, DC/OS from Mesosphere and Nomad from Hashicorp.

The application itself is made up of multiple microservices written in Go (with GoKit), Java (with Spring Boot) and Node.js, which also make use of supporting services such as RabbitMQ, Mongo and Nginx. All of the services run in separate Docker containers. Services communicate using REST over HTTP. It has been designed from the start with current microservice and cloud-native best practices in mind. In short, it would seem to be a great candidate to form the basis of a cloud-native reference application.

It would be great to find out how these pieces of “Sock Shop” can be replaced or refactored with different technologies, and what effect this has on the overall application. What would happen to the networking overhead if it used RPC calls and protobufs for communication? How easy would it be to integrate a monitoring and alerting framework? What about using rkt or VMs instead of Docker?

If you have an idea that you’d like to implement or suggest, please head over to the microservices-demo GitHub repository and submit a PR or feature request.

Docker, Mesosphere and Weaveworks are sponsors of InApps Technology.

Feature image via Pixabay.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.