Microservices & DevOps - (Gartner Roundtable Event)

Mar 14

Mar 14 Microservices & DevOps - (Gartner Roundtable Event)

On Wednesday, March 6th, 2019, I had attended a work sponsored event at the SUNY Polytechnic Institute’s Albany campus. At this roundtable event Kevin Matheny, of Gartner for Technical Professionals, covered many aspects of modern webservices delivery. From industry titans like Google, Amazon, Facebook, and Apple, many aspiring enterprise-level companies are now turning to concepts such as virtualization and containerization to deliver measurable returns on investment.

Rather than talking in investment terms, Kevin took the room on a two-part journey through the right ways to approach development of microservices and how to cultivate the talent needed to master microservices delivery. His first presentation was “The Path to Microservices,” before a break and his second presentation, “Keys to DevOps Success.” The titles themselves were great for people in the know, but what does virtualization, containerization, microservices, and all the rest of this even mean?

Virtualizationᶦ is a key concept where all the hardware resources servers need to store and compute, can be provided by software instead, virtually, within the memory and hard drive space of large specialized servers. Rather than having multiple physical servers handling small dedicated workloads; they can be consolidated into one physical server running multiple guest operating systems. Virtualization also allows existing hardware to be repurposed to add storage and computer nodes, where any additional host CPU power or disk space is immediately put to good use for the benefit of the guest operating systems. Recovery time from a failed virtual server can also be reduced tremendously with common tools such as snapshots,ᶦᶦ backups, and replication.ᶦᶦᶦ

Containerizationᶦᵛ is another key concept where applications are taken apart and modularized by their application developer so that niche functions of an application are taken care of in their own virtual work spaces. The three tiers of functions encountered are the application, the application’s engine, and the application’s storage. Rather than putting the application on one server, the application’s engine on a second server, and the application’s storage on a third server; the application is reimagined to function entirely within one container that abstracts all three tiers through virtualization.ᵛ Each container provides the resources needed for its functions, and nothing more, making containerization a very efficient means of operation in this context.

Microservicesᵛᶦ bring together both concepts, and more, to develop applications that can instantly and effectively scale up or down with user demand. The example Kevin gave in his talk was the BestBuy website before and immediately after Thanksgiving. During the rest of the year, their website may have a million visitors a day; and of those, maybe 20,000 customers will make a purchase. Right after Thanksgiving, aka Black Friday, their website scales-up on the demand of ten million users or more, with at least one million users making purchases.

BestBuy’s microservices architecture orchestrates the creation of new application instances. The greater the user demand, the more instances of the microservice that are created. The webservice applicate itself being separate from the order processing application, and so on. As user demand tables off and declines, extraneous instances are destroyed with the greater system only hanging on to the resulting data from each instance.ᵛᶦᶦ

Mr. Matheny drilled deeper into qualities that define this still nascent technology as he continued down “The Path to Microservices.” Microservices, he said, must be both loosely coupled and highly cohesive because of the niche-style nature of the architecture. In the above example, the microservices that present the BestBuy website to the Internet are separate-yet-connected to the ones that handle order processing. For shipping the orders, retailer microservices interact with shipping providers microservices. Be it FedEx, UPS or USPS, companies at this level maintain application program interfaces for their business partners to exchange data with, known better as APIs.

Think of an API as a special telephone line, for example, from Amazon to the Postal Service. Amazon knows the line only goes to the Postal Service, and the Postal Service knows on the other end when they pick up will only be Amazon. This is a secured line, and Amazon can pick up it up anytime to conduct business with the Post Office, no waiting, no busy signals. Only now this is the digital age, and digital transactions are taking place rather than voice conversations. Sharing API access across a supply chain is only the beginning of a long list of improvements that microservices can provide to prospective industry partners.

The BestBuy example Mr. Matheny gave was a real-world example, as was my Amazon and Postal Service example. Both scenarios are currently being adapted across a very diverse workload from hospitality, ecommerce, finance, transportation and logistics, and many more, thanks to expert teams of developers and operations specialists. DevOps, as the teams are known, were formed to bring microservices architecture to the enterprises of the world.viii Masters in their craft are required to securely expose the APIs to the Internet, to remodel and match code to modules, and enable scaling. The boundaries between the inner architecture of a service and the outer architecture of the platform are tended, respectively, by development teams and operations teams to ensure delivery of business outcomes, not technical improvements.

In his second session, Kevin’s “Keys for DevOps Success” delivered a third set of qualifications to an already-robust skillset. Success with DevOps is never done, requires business focus, a willingness to effect changes in business culture, and continuous improvement. It’s possible to have a development team on one hand and an operations team on the other hand, without having a DevOps team if the two don’t actively collaborate.

Success in this context requires constant iteration, along with changing the way that everyone in the company works, not just the members of the DevOps team. Kevin brought in concepts during his talk from methodologies like Agile,ᶦˣ SCRUM,ˣ and Extreme Programming or XP,ˣᶦ further cementing the idea that proper business acumen is not remised in team members. Loosely quoting Mr. Matheny, everything we’ve already built must be more important than what we’re going to build, otherwise the entire process won’t succeed. I learned a lot about the operational roles my colleagues and I have in MSA and DevOps, both as data center networks specialists, and myself as a cybersecurity student.