Securing A Multi-Cloud App With Service Mesh

Multi-cloud is becoming a reality for many organizations, but what is multi-cloud? Multi-cloud is a very wide term that encompasses any organization using more than one cloud, whether running apps across those clouds or not. For example, if one BU in my org is using GKE and another BU is using AWS my business is already operating in a multi-cloud environment, and this needs to be operated and secured. 

So we have defined multi-cloud, what is hybrid cloud and what are multi-cloud app then? The “hybrid-cloud” term came out very close to the emergence of public clouds and private clouds. Hybrid just like public and private is about location. How do I connect the public and the private clouds, mostly from the infrastructure point of view. The hybrid-cloud seems more and more suitable for “heritage workloads” cloud migrations where the “hybridity” is about connecting distinct pieces of infrastructure together for the ability of either moving stuff to the cloud or bursting to it. Multi-cloud apps, which this article focuses on is when we run an application through multiple clouds. read more

Service mesh is just another form of virtualization

When I started working with VMware ESX in the early 2000, I knew it was a very cool tech; and not only me, everyone knew there’s something special about it.

However, I haven’t fully grasped the full value of this technology right of the gate, at that point, I only saw “server consolidation” in front of me.

When vMotion came out, and we realized that physics has changed for our servers, we were no longer tied to the hardware the Server was running on. That hardware abstraction allowed us to do things we couldn’t do before. like fixing hardware issues or patch it with no downtime, scale much better and faster by deploying VMs when we need them and monitor the health of the infrastructure much better, even self heal. A new exciting world of agility we never saw before was opened.

 

Due to the above combined with automation, the effort of managing servers has been lowered, and fewer people are needed to manage fleets of servers.

What does that has to do with Service mesh you ask?

Recently I started focusing on Service mesh, mainly Istio, testing it in the lab, learning the technology and feeling that magic again. While the technology is cool, I was trying to understand the business value that is more than buzz words like distributed, load balancing, observability etc. However, at some point, I realized that I was looking at it all wrong. I was looking for the value from a networking operations point of view, it’s only when I looked at it from a developer value when it clicked.

Service mesh is a form of virtualization

When I get excited, I let the world know, that’s why I love twitter

I see much equivalency in Service mesh to virtualization.

In the monolithic app world, many of the different pieces of code that compile the application or service are running on a small set of servers, so making decisions about how that component interacts with other parts of the application are written in the code.

That means that for every piece of meaningful code that differentiates the business the application is servicing, need to have much non-differentiate code along with it.

Things like server and client side communication, service lookups, error detection and response, telemetry, security are taken care of in the code or middleware software.

With the rise of micro-services (and the use of containers for that purpose) each container now runs a piece of differentiating code and is a single purpose server that communicates with other services on the network. The distributed architecture and the proliferation micro-services, bring new challenges to manage, monitor and troubleshoot problems.

 

What service mesh and Istio does is outsourcing the non-differentiating work to the sidecars with Envoy where each k8s pod now has a proxy that is responsible for communicating with other proxies and out of the mesh. (Envoy can work with more than k8s pods, it can even work with VMs or Pivotal PAS AIs!)

Now we’ve abstracted the non-differentiating code. Similarly to the value we gained by virtualizing the hardware with the hypervisors and adding a control plane, we gain for the operations of the proxy by adding a control plane in the form of Istio (I will not go into the deeper architecture in this post, there are literally hundreds of posts about it out there)

Here is a diagram to illustrate the abstraction layers in one picture

We can apply our desired state as policies to anything that is not the core function of our software, change policies on the fly without changing our code which saves much effort spent by developers, dynamically changing the policies without changing any code, apply security and authentication to transactions and have better visibility into the application health. Self-healing becomes a real thing now.

But just like virtualization brought its own set of challenges, Service mesh is no different,  which I will cover in my next post.

You can read more about the details of Istio features in this blog post: https://blogs.vmware.com/opensource/2018/10/16/service-mesh-architectures-inevitable

I think this analogy explains the subject, and the proliferation of abstraction layers brings a new set of challenges from a management point of view.

Have any thoughts on this? tweet your reply

@niranec

Niran

What are these Spectre and Meltdown vulnerabilities all about

For any of my friends that are not computer savvy, or usually don’t care. In this post I’ve digested the info for you about the security bug in CPUs, which is a BIG DEAL. You will start to hear the words like #Meltdown and #Spectre alot soon regarding your computer security. Allow me to explain in very high level, hopefully this helps some of you to better understand the biggest security bug in history :
Meltdown is the name of a vulnerability found in Intel CPUs only, where 

security is compromised to gain more speed. Basically Intel engineers designed their CPUs to be more performant but neglected to make sure they are secure enough, and the result is that one piece of code running on an Intel CPU can read the “kernel memory” of the operating system (OS) . Think of the kernel memory as your brain’s secret thoughts, what would have happened if I gained access there? In the computer world that’s where all your passwords are for example.
The patches that are coming out for this one are on the OS side (windows, Linux etc) and they expect to slow down all Intel chip sets by 30%-50%. Yes, your computer will be slower.
Do not underestimate this problem, code and guides how to exploit this vulnerability are already surfacing. (see link below)
The second name you might hear is “Spectre”. This is a vulnerability that affects ALL cpu vendors. And the worst thing, this cannot be patched, it’s a basic design flaw and it will stay with us for at least a decade until the current HW cycle gets refreshed world wide. Fortunately this one is much harder to exploit. We will have to see how this rolls out.
Most worrisome use case besides getting the password of your grandma back accounts, is shared HW, especially in the cloud. Think of one customer who rents compute resources from the cloud and is able to read password and data of other customers running on the same HW. Maybe your bank is the victim? And this affect everyone!
That’s it, hope this helps, let me know your thoughts.
Those who wants to read more see this link https://meltdownattack.com/ read more