Though I originally studied application development and programming in school, and even did a bit of work as a web and database developer earlier in my career, I opted to change my focus to be more about infrastructure in IT, rather than the applications pretty early on. My background in applications and development always helped in my infrastructure positions, its always good to have some idea what the other guys job is like, but for many years I just found the infrastructure side to be more interesting than applications. However, just as technology continues to change, so has my interests.
It’s hard to put my finger on exactly what or when I started to pay closer attention to what was going on in the development space, but at least for the last six months I’ve been spending far more time in areas closer to the coding and development than more traditional infrastructure spaces. It likely started with “Cloud” becoming a household word, and then came “DevOps” and “Cloud Native Applications”, and now “Digitization” seems to be the latest buzz word flying around.
I didn’t jump right back into the development side of the pool, and to be fair, I’m still far from completely in the deep-end, but I began brushing off skills that had gotten covered in cobwebs. Having been primarily a .NET and Java developer in the past, I took a look at the current language landscape and decided to learn Python as a new language to work in. I embraced the land of “NoSQL”, something that is still difficult as I spent so much time learning the value of “Normal Forms” and “ERDs”, but I’m definitely seeing the value of document databases like Mongo. And of course I embraced “Agile” methodologies instead of the Waterfall approach I’d been taught.
One of the hardest things to pick-up purely based on reading blog posts and writing toy-code, was what really meant by “Cloud Native Applications” or “Microservice” applications. Sure, I learned a lot by going though material like the 12 Factor Application, but I wanted to get a much deeper understanding. And I knew the only way to really do that was to build a “Cloud Native Application”, abiding as many of the principals of Microservices as I could. I’m also a very practical “show me” kind of guy, so I knew having a demo application more interesting than WordPress or a Hello World example that I could use as part of my day job would be very useful and helpful.
The Legacy MyHero Application
And with the goal of building a “Cloud-y” application set, the next step was to figure out what to build. For that I actually dusted off a project I built about a year earlier to demonstrate how Cisco’s Intercloud Fabric technology could be used to deploy a Hybrid Application.
MyHero is a very simple application that lets users vote for their favorite superhero. It provides a web portal for users to place their vote, view the current results, and get some information about the application itself. Other than being written in Python, the first version of MyHero (original project code on GitHub) was not very modern or cloudy. It was a standard three tier (web, app, data) application, with each tier being more similar to a legacy VM centric “pets” model than a modern microservice and “cattle” application. What it did provide was a good place to start, as many organizations are faced with the challenge of updating legacy applications to meet the needs of the “Cloud”.
MyHero Goes Cloud Native
And so MyHero Cloud Native Demo was born. Though the application and containers each service leverage could run in any environment, it was designed and has been heavily tested and used with the Cisco Mantl.io microservice platform. In addition to being a personal learning exercise, I designed and built it to be easy for others to use as a demonstration application for Mantl (takes less than 10 minutes to deploy to a working cluster), as well as an application framework to learn and extend Cloud Native strategies. All the code is up on GitHub and I look forward to adding new features and making it an even better demonstration and learning tool.
How MyHero is “Cloudy”
I’m not going to go through all the steps that I went through to convert the original application to its current state (at least not in this blog post), but here’s a quick run down of what I did, and to some extent why…
- Break the single code base into individual directories and code repositories per microservice
- This makes each microservice more independent from the others, and decouples the development of one from the others
- Build Docker containers to run each of the original services (web, app, data)
- Containers provide extreme portability across environments and platforms
- Pull all environmental configuration settings out of the code, and replace with references to environment variables
- Other than being one of the guiding 12 Factors, it just makes good sense for application portability and ability to use the same exact code in development on my laptop, testing in the lab, production on my demo cloud, as well allow anyone else to easily leverage the application in their environment
- Retroactively build Vagrant support for local development
- Originally I developed and tested the application on my Mac with the native Python environment. Mostly because I didn’t know any better. I took this opportunity to leverage Vagrant to deploy Docker containers on my laptop to closely approximate a production deployment.
- Scaling support of the Web and APP/API layers using load balancing and proxy servers
- The original architecture supported putting a load balancer in front of the tiers, but its as a very legacy approach. In this new model, the application deployment assumes that the container stack provides support for load balancing applications. In most cases where MyHero is being used, the Container Stack is Cisco’s Mantl.io stack which leverages traefik in front of Marathon to load balance all services.
- Build additional User Interfaces outside of a basic Web Portal for the application
- I added new services leveraging Cisco Spark and Tropo as alternative methods to vote for your favorite super hero
- Today users are expecting to work with their applications in many ways other than a web page or their mobile phone. An application architecture needs to support rapid addition of new interfaces through a common API framework.
- Leverage an Message Queueing (MQTT) layer between APP and DATA for scale and resiliency
- One of the big problems in applications are single points of failure and bottlenecks for performance. In its current state, the data service is both and I needed a way to limit this exposure. By implementing a queue I drastically reduced the potential for overloading the data service during high traffic demos or use.
- For similar reasons as the MQTT Server, I wanted to limit the load on the data tier for repeated access to the same data.
I’m not done with MyHero at all… there is a list of things on my backlog that I want to add to the application to continue exploring Cloud Native Development concepts and practices, but I am pretty happy with where it is currently. I’ve learned so much from the project, and I’ve had others leverage it for their own demos and work. If you’ve read this far, and are looking for a place to get started in understanding “Cloud Native Applications”, hopefully you’ve found this article interesting, and please go grab the MyHero code and let me know what you think.