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.
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.
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.
— Frank Hinek (@frankhinek) July 27, 2016
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.
Feature image via Pixabay.