Monday, May 04, 2020

Cloud Field Day 7 - VMware Cloud on AWS

For those who are traditional VMware enterprise customers you are likely comfortable with their products and technologies and rely on it daily to help keep your company up and running in a highly available configuration. Adoption of public cloud, that is a different story for many. If you have not been keeping up with the innovations and use cases around public cloud you might be caught off guard by the adoption and scale that it is providing to many enterprise customers, some of them might even be your competitors. VMware recognized this gap and decided to brave the waters by partnering with Amazon Web Services (AWS) to make VMware Cloud on AWS. For anyone who has followed the public cloud market, you will be familiar with how daunting that can be for a well established enterprise software company like VMware. A lot of other software companies have tried and failed to move their solutions and buying patterns to a public cloud model.

Remarkably, I think VMware pulled it off. At least for now. They released a solution to help customers run workload in AWS and take advantage of their existing investment in VMware. They extended that to the scale and flexibility that AWS provides while also providing native hooks and features from AWS that extend what an enterprise can leverage from both VMware and AWS. Granted, it is not like going all in native AWS, but, for many companies that effort is incredibly daunting and likely too large an undertaking for any one team. A major workload migration of applications and services for many companies requires multiple projects and years to complete.

VMware is helping address this gap by allowing enterprises to migrate workloads into AWS but still leave them in their native VMware format. The tools and constructs (Software Defined Data Center or SDDC) that VMware customers are used to stay the same, so they can just leverage running them in AWS. This flexibility gives customers more time to determine what is the right environment, cost model and workload placement for their needs. Long term, I still believe that most customers will figure out how to properly leverage native cloud services (from all the public cloud providers) but this solution is a smart way to address an immediate need that will last several years. I think of it as the "easy button" for enterprise IT teams who need to have workloads running in AWS to help support their organization.

Day 1

Day One of VMware Cloud on AWS


The day one presentations at Cloud Field Day 7 focused on an overview of the offering, a deep dive into the networking and how that works, details into data center extension and hybrid cloud, and finally how to do migration and the tools available to you. If you are not familiar with VMware Cloud on AWS then watching these videos will go a long way to understanding what is offered. It is a unique offering, even though VMware has agreements with Microsoft Azure and Google Cloud the integration and partnership is different. I won't belabor the points of how they are different, theses presentations were all about the AWS offering, just know that the work and partnership has been more extensive. I would recommend the migration and networking presentations if you already know a bit about VMware Cloud on AWS, it helps to explain how you will leverage what they have built out.

 


Day 2


Day Two of VMware Cloud on AWS


The day two presentations jumped into specific services and attributes of the solution. It went over virtual desktop using Horizon 7 on top of VMware Cloud on AWS - I'm not entirely convinced this is any better than Workspaces that AWS provides, but it does keep things the same if you have already deployed Horizon 7 on-premises. DR as a Service (DRaaS) was up next showing off how to leverage SRM, very straight forward, they really did make this part easy for admins. No cloud service offering can go to long without bringing up Kubernetes (K8s) and this was no exception. The offerings and options are pretty overwhelming so check out the video for more information if K8s is your thing. If you want to integrate your VMware Cloud on AWS with native AWS services then you need to have a method to make that integration work. They presented on how this functions (it is slightly different than if you are used to using AWS service endpoints). Many organization who want to leverage application streamlining make use of marketplaces and pre-build packages to make standing up well known applications and platforms a bit easier. VMware has a cloud marketplace for that purpose. I'm not sure how viable their marketplace will be long-term given the ease that you can deploy from the AWS Marketplace to a VPC and leverage that native ability but it is a "nice to have" in the current transition for those that can't deal with porting their apps or platforms.

So what does this mean for enterprises running the full suite of VMware products and technology?
  1. You have a relatively easy way to getting your existing environment running in public cloud - but it really isn't public cloud in how the IT market defines it. You are leveraging public cloud infrastructure and a few of their constructs but you are really running VMware SDDC as a Service.
  2. You will be paying to run your existing application and platforms in AWS but you won't have as much control over size, scale and costs as if you were to do the effort to port and move to AWS.
  3. You will have to address a shared administrative role and permissions (VMware is running the environment in AWS for you), some enterprises that is a deal breaker.
  4. You need to evaluate the benefits this solution versus starting to adopt public cloud in an incremental way and port or migration your applications to a native cloud architecture.
  5. You can potentially reduce or completely decommission any data centers you operate for disaster recovery or high availability reasons and leverage VMware Cloud on AWS and scale as needed.
  6. You could use VMware Cloud on AWS to potentially spin out a division or company and then hand off that infrastructure, applications and platforms to a new team with much less headache than moving things out of your data center.
  7. You will still have data gravity problems, they just won't look the same as they do for public cloud services.
  8. You will need to have a savvy networking team as the requirements around VMware NSX and AWS networking services are not going to get easier.

If you decide to watch the videos and you have a question feel free to hit me up on twitter (@ehorley) and use hashtag #CFD7, that way others can jump in to help if I missed it. I'm always interested to hear a different perspective or view about a technology, let me know what you think about VMware Cloud on AWS and if it is a good solution for the market right now.
- Ed

In a spirit of fairness (and also because it is legally required by the FTC), I am posting this Disclosure Statement. It is intended to alert readers to funding or gifts that might influence my writing. My participation in Tech Field Day events was voluntary and I was invited to participate in CFD7. Tech Field Day is hosted by Gestalt IT and my hotel, transportation, food and beverage was/is paid for by Gestalt IT for the duration of the event if travel was involved. In addition, sometimes small swag gifts were/are provided by some of the sponsors of the event to delegates. It should be noted that there was/is no requirement to produce content about the sponsors and any content produced does not require review or editing by Gestalt IT or the sponsors of the event.

Tuesday, April 21, 2020

Cloud Field Day 7 - All virtual but still a Tech Field Day event in every way

Adapting to the times is a given in the technology field and the current worldwide crisis around COVID-19 has forced some changes for Tech Field Day events and the Cloud Field Day 7 event starting April 22, 2020 in particular. We will be doing everything online and while I will miss getting to hang out with many of my friends and colleagues who will be participating it is nice to know we can continue to contribute and engage in this fashion.
So check out the live feeds and videos, it all starts Wednesday morning at 8 am PDT. The line up of sponsors is good. We will be hearing from these sponsors over a few days, check the site for specifics:

If you decide to watch and you have a question during one of the live sessions feel free to hit me up on twitter (@ehorley) and I will see if I can get it asked. You can also just use hashtag #CFD7 and others can jump in to help if I missed it.
- Ed

In a spirit of fairness (and also because it is legally required by the FTC), I am posting this Disclosure Statement. It is intended to alert readers to funding or gifts that might influence my writing. My participation in Tech Field Day events was voluntary and I was invited to participate in CFD7. Tech Field Day is hosted by Gestalt IT and my hotel, transportation, food and beverage was/is paid for by Gestalt IT for the duration of the event. In addition, small swag gifts were/are provided by some of the sponsors of the event to delegates. It should be noted that there was/is no requirement to produce content about the sponsors and any content produced does not require review or editing by Gestalt IT or the sponsors of the event.

Monday, January 13, 2020

Network Field Day 21 - NGINX - Making Sense of Service Mesh

NGINX presented on their service mesh solution at Network Field Day 21, and you should check out the presentation by Faisal Memon explaining what they have built. He explains what a service mesh is, why you might need it and how it is integrated into NGINX.

If you have spent any significant time as a practitioner in network engineering you will eventually end up helping with a project that involves a distributed publish/subscribe message system - which today we call a service mesh. In earlier times, we might have referred to it as a service or message bus and used technology like the Common Object Request Broker Architecture (CORBA) which is a standard developed by the Object Management Group (OMG) to provide interoperability among distributed objects. Or maybe you installed and used a commercial software solution like Tibco Rendezvous which has been around for 20 years or you were involved in the financial industry and you implemented the FIX protocol.

My point is, the concepts and design ideas for a service mesh have been around for decades and really are nothing new at all. Effectively, they are a distributed message queue with a standard API run over a network. What has changed over time is the ubiquity of their use in many common platforms and architectures today. I believe one of the reasons so many platforms use them is because developers have become increasingly frustrated with the networking NAT/PAT/DNS problems and would prefer to have a more elegant routing and name space than what classic IPv4 and DNS provide. There is a lot to unpack around that last sentence and I likely won't get to it in this post but just accept that the way many enterprises are deploying and running their network are not optimal for application developers trying to deploy new application workloads within the data center environment.

There are many options to choose from for a service mesh. A not so brief list of some options would be:
Istio/Envoy
Console Connect
Linkerd2
Maesh
NGINX Service Mesh
Microsoft Azure Service Fabric
RabbitMQ
Hashicorp Consul
AWS App Mesh

Because of the role that a service mesh provide, it matches very cleanly with application proxy services. This is a natural fit for something like NGINX because that is where it is commonly deployed too. Often NGINX is used as an application delivery controller (ADC) or a classic server load balancer (SLB) along with a proxy for application traffic. This proxy role allow NGINX to have a comprehensive view into the application, even with a distributed application front end. Providing a sidecar proxy function to allow more enhanced services to be managed and run without burdening the application developer is one of the benefits you gain. For example, TLS certificate management, mutual TLS (for secure app to app communication), tracing and monitoring, metrics and reporting, traffic controls and any other services can be coordinated, synchronized and managed separately from the application and not burden the developer with having to know all those specific items to get their application work.

One of the benefits of having a service mesh built into NGINX is the fact that NGINX is now the most widely deployed commercially supported web server in the top 1000 websites. This means that having a service mesh solution integrated into the platform makes adoption and use of a service mesh far more likely to occur because NGINX is used in so many places and in so many deployments. The other interesting part is the fact that many service mesh solutions can be swapped in and out depending on the need requirements of the application developers. That means that other platforms can either leverage with NGINX has build with their service mesh technology or they can swap it out and use Hashicorp Consul or whatever other service mesh technology they are already utilizing. It is very flexible and it is a technology all network engineers should be comfortable helping deploy, operate and support in their environment.

So it is highly likely, at some point, you will be involved with some a project that makes use of a service mesh and you should take the time to learn and understand how it is used and commonly deployed. Because of the popularity and wide scale adoption of NGINX it makes a lot of sense to have a good understanding of what they have built and how to use it.
- Ed

In a spirit of fairness (and also because it is legally required by the FTC), I am posting this Disclosure Statement. It is intended to alert readers to funding or gifts that might influence my writing. My participation in Tech Field Day events was voluntary and I was invited to participate in NFD21. Tech Field Day is hosted by Gestalt IT and my hotel, transportation, food and beverage was/is paid for by Gestalt IT for the duration of the event. In addition, small swag gifts were/are provided by some of the sponsors of the event to delegates. It should be noted that there was/is no requirement to produce content about the sponsors and any content produced does not require review or editing by Gestalt IT or the sponsors of the event.