Serverless Computing is an architectural approach for application development that emphasizes on the stateless function execution as a response of an event trigger. In order to take advantage of this approach one needs to actually make use of a runtime platform (a set of servers) to execute these stateless functions in (… and yes serverless does not mean you don’t need servers – you do). There are various implementations of such FaaS (Function as a Service) runtime platforms both for on-premise and in the cloud. One of the most used today for in-cloud function execution is provided by AWS.
VMware Cloud Automation Services is playing a big part in VMware multi-cloud strategy. If you are new to the VMware Cloud Assembly Services, I encourage you to checkout the following sources for a quick overview first:
- Introducing VMware Cloud Assembly, VMware Code Stream and VMware Service Broker
- Cloud Automation Services – Cloud Assembly Technical Overview
Today we’ll take a look how VMware Cloud Assembly can make use of AWS Lambda for workload lifecycle management through Action Based eXtensibility (ABX). This is mechanism suitable to those organizations that are implementing a cloud-first or hybrid cloud approach and have their integration endpoint dependencies accessible as SaaS services. Making use of ABX for on-premise endpoint integrations would require additional components that are outside of the scope of this post.
Can you elaborate a bit?
Alright, let me give you some perspective…
As depicted the provisioning flow will consume a Blueprint and will produce a Deployment on a Cloud Account you have defined (e.g. VMware Cloud on AWS). The provisioning flow will produce several events for the different stages it passes through. We can subscribe to each stage and alter/enrich its behavior. One can chose to subscribe and handle the subscription event through a vRealize Orchestrator Workflow or through ABX that relies on AWS Lambda Functions, as shown here.
Since we are talking about Serverless stateless functions it should be clear that the Lambda Function called by ABX will be instantiated in a new isolated container that will be active for the duration of Function execution and then the container will be destroyed. The Function will realize the orchestration (business) logic only and any dependencies it may have will need to be provided by other external services, for example AWS S3 for object storage, Service Now for CMDB or Slack for notification handling.
How do I get started?
First things first, let’s run through the minimal configuration on AWS side so you actually have a place to execute ABX in.
In AWS Console navigate to IAM Service and (and yes you need to have an AWS account activated to login):
- Create a new Role and assign it permission policy of AWSLambdaBasicExecutionRole. Let’s call that lambda-basic-role. Make a note of its ARN identifier (looks something like: arn:aws:iam::82927:role/lambda-basic-role)
- Create a new Policy (for example, CASDeployLambdaRole) and limit it’s permissions as minimum to:
- Service: Lambda → Read: GetFunction → Write: CreateFunction, InvokeFunction, UpdateFunctionCode, DeleteFunction, UpdateFunctionConfiguration → Resources: All resources
- Service: IAM → List: ListRoles, ListAttachedRolePolicies → Resources: role = Any
- Service: IAM → Write: PassRole → Resources: Account = 82927 & Role = lambda-basic-role (you guessed it, these are found in the Role ARN)
- Create a new user (for example, cas-lambda) with programatic access and for permission policy set CASDeployLambdaRole. Take a note of both Access key ID and Secret access Key as we’ll need them later.
The above will provide the minimal permissions for VMware Cloud Assembly to deploy and configure your Functions for execution on behalf of the cas-lambda user you created. You can chose to assign more permissions to that user, for example to be used for workload provisioning.
Ok, let’s go to the other side. Bring up VMware Cloud Console and navigate to VMware Cloud Assembly service.
- Navigate to Infrastructure > Cloud Accounts > Add Cloud Account > AWS
- Paste the Access key ID and Secret access Key you got during cas-lambda user creation and click Validate
- Name the cloud account (e.g. cas-lambda)
- Select one of the regions which you want your lambda function to execute in. Since you set Resources: All resources above you can pick any or all if you want.
- Ensure “Create a cloud zone for the selected regions” is selected and click Add
Ok that should cover the Cloud Account setup and basic Cloud Zone setup.
Let’s verify there are no loose ends. Grant a project access to one of the Cloud Zones you created and test it.
- Navigate to Infrastructure > Projects
- Create a new Project or use an existing one
- Add a Cloud Zone from cas-lambda Cloud Account
- Navigate to Extensibility > Actions
- Create a new Action
- Chose “Custom script” for template
- Assign the project you have enabled for AWS Lambda execution above.
- Chose “Nodejs 8” for runtime. This will produce a sample template script to execute with and you can leave the rest as is for now.
- Click Save
- Click Test (if you have only one project so far the one you configured above should be used by default, otherwise ensure it is set during Testing to avoid failures)
If everything is ok you should see more green than red when you click See details button as well as the Input/Output execution context. Here’s how it looks on my end:
I got green… what’s next?
Great! Then you are ready to start exploring and extending your workload provisioning through defining some Lifecycle Subscriptions.
For me it will take another post to cover what’s possible with ABX in more details and to provide you some good examples. Stay tuned…
EMA Quick Take
Since our launch, Torsten Volk at Enterprise Management Associates did a “Quick Take” on our Cloud Automation Services. Torsten did a great job summarizing our services and the pain points we are addressing in the market.
Have you had a chance to try our new services and see how they could impact your organization? Sign up for a free 30-day trial today! It’s easy to get started and super-fast at getting workloads across public, private or hybrid clouds.
