Featured Future:NET 2018 Tech Talks VMware

It’s All About The Speed!

  1. The Future:NET is Service Mesh?
  2. Service Architecture: The Times They Are a-Changin’
  3. Is a Cloud-Native Network OS Required?
  4. Future:NET – Missing the blockchain future?
  5. It’s All About The Speed!
  6. Future:NET 2018 Unified SDN for Microservices: Reality or Fantasy?

In my previous article, I talked about one of my favorite sessions of Future:NET. Today, I’ll talk about my other favorite session by Ken Owens, VP Cloud Native Engineering at Mastercard. He is also a founding member of CNCF (Cloud Native Computing Foundation).

Ken’s presentation continued with the “Cloud Native” theme (hence my interest) and it was called “Digital Transformation at the speed of Digital Transactions”. The focus of his presentation was on both the technical and non-technical considerations when starting on a cloud native transformation journey.

I would highly-recommend you watch this session because it touches upon many aspects of service architecture and provides food for thought.

Living on the Edge

It was interesting to hear that Mastercard is operating on the cutting edge of development methodologies. For example, Ken talked about the use of GitOps, as compared to your standard CI/CD methodology. If you’re interested to know more about the difference, there’s a very interesting blog by Alexis Richardson explaining what it is all about.

He also talked about why it’s absolutely essential to have dependable, secure and lightning fast services at Mastercard. That’s not surprising given what they do but one can imagine the amount of effort that must go into optimizing speed at every level. The application has to not only work fast but also fail fast. All of that while keeping all components secure at the same time.

Service Mesh Again?

Given what Mastercard wants for the service, it’s not a coincidence that they are looking to configure, control and monitor their application infrastructure using a method that would simplify those operations and make them scalable and fast.

Ken mentioned that Mastercard has recently started using Istio, which is the preferred choice for many organisations, given its flexibility with containers/VMs alike and support on all major cloud platforms. A major goal for Mastercard is to use this mechanism to manage the keys that all components use to securely communicate with each other. Service mesh enables a cloud native way to provide keys to the application teams securely and relive them from the worry of developing for authentication, scaling and other infrastructure-related artifacts.

The other aspect is decoupling of services. As Mastercard transforms its applications into microservices, these services need a standard way of subscribing to each other as required. Service mesh provides a proxy to each service that handles the required communication in an efficient and scalable manner.

While he was complimentary about all the benefits that Istio brings to their cause, Ken highlighted Traffic Management, Security and Observability as the key capabilities they benefitted from the most. In addition to the standard monitoring aspects of observability, it also allowed them to improve their services by looking into application behavior and identifying issues that otherwise may not have been so apparent.

The beauty of this architecture is that the developers don’t have to worry about infrastructure and authentication anymore. They just need to bind their application with appropriate certificates and security constructs. The rest is handled by Envoy which manages the communication side of things and scales the various services as required.

People and Process

While talking about the key elements of a successful transformation, Ken made an important point about the importance of people and process when working with change in methodology and the related technologies.

It doesn’t matter which technology or tool is used to address the business challenges that face us as it will eventually work. What is important is to have a consistent and effective process and the buy in from people who are going to execute it. Without them, things will fall through the cracks and the implementation will fail.

This has always been the case but it’s even more important when developing for such highly-distributed systems which are designed to provide scalability.

There is hope!

It was very interesting to hear Ken’s experiences from a financial services provider standpoint. His presentation was proof that everyone has the same problems when trying to make the transition to cloud native; it’s just that size of the problem might be different.

That said, it does give assurance to everyone else embarking on this journey that they’re not chasing an impossible dream. The technologies and tools are already available and by following best practice, defined by the leading organisations already treading this path, their transformation should be achievable.

More importantly: If it’s good enough for these trendsetters, it’s good enough for the rest of us.

About the author

Ather Beg

Ather is a Solutions Architect and works for Rackspace. His focus is on all things related to cloud, technology, storage, virtualization and whatever comes in between.

Being in the industry for over 20 years, he feels ancient. If you feel that inclined, he can bore you with stories on how he used to manually park heads on a hard drive or bound protocols to network cards. Seriously though, he has designed, deployed and managed many enterprise environments, involving virtualization, storage, directory and mail services.

Leave a Comment