- Software Development
- A Cloud Native Reference Application – InApps Technology 2022
A Cloud Native Reference Application – InApps Technology is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn A Cloud Native Reference Application – InApps Technology in today’s post !
Read more about A Cloud Native Reference Application – InApps Technology at Wikipedia
You can find content about A Cloud Native Reference Application – InApps Technology from the Wikipedia website
Adrian has been involved with containers from the early days of Docker and authored the O’Reilly book Using Docker: Developing and Deploying Software with Containers. He is currently chief scientist at Container Solutions, a pan-European company focusing on consulting and product development for microservices and containers. He is a member of the Docker Captains program.
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.
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.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.