Introduction
In a software-defined world, infrastructure is defined by policies based on a set of requirements — prescribed by the business, applications, security or IT itself. Those policies are tied to a set of logic that integrates and automates a given service as needed, when needed. For its part in the SDDC stack, vRealize Automation (vRA) binds defined policies to services using a variety of configuration elements. At request time, policies can invoke governance, workflows, app-centric services, and integration with external systems via a robust extensibility platform. Policies simplify management of the deployed applications or services throughout their lifecycle…up until decommissioning, where vRA can undo the entire stack. Along the way, vRA provides total transparency, greater controls, and deeper integrations into external systems, catering to the control mongers who are hesitant to adopt automation (especially in regards to networking and security).
The driver behind all of this is the fundamental need for automation across the enterprise. We automate to reduce or eliminate the many repeat tasks associated with provisioning a service…with the added benefit of removing the error-prone human factor. Whether that’s for provisioning hundreds of boring VMs, building complete application stacks, or deploying complex enterprise applications that incorporate a massive 3rd party ecosystem, the ability to integrate and automate the IT stack per the application’s needs is an essential function of the modern enterprise. That holds especially true for some of the more complex and time-consuming tasks related to networking and security operations.
Now ask yourself — how many dormant ACL’s exist in your firewalls? Do you follow a rigid process for cleaning up firewall policies each time an application is decommissioned? Rogue firewall policies are a significant threat and, at the very least, can cause serious heartburn while troubleshooting a new app’s access issues if it happened to share the IP of a decommissioned app. Imagine the benefits of having those same policies automatically provisioned – and decommissioned – based on the application’s lifecycle policy. No need to imagine – this post will dive into many of the features and benefits gained when vRealize Automation 7.3 and VMware NSX come together to deliver Application-Centric Networking and Security services to the enterprise.
vRealize Automation: A Primer
vRA is designed to bridge the gap between a pure consumption model and on-demand everything. It does this by natively supporting both concepts (plus some combination of each) to appease those who are just getting their feet wet and those who ready to rumble. Requests are initiated from vRA’s unified catalog. From the consumer’s perspective, the apps and services needed to do their job are readily available. They can select the desired catalog item and be on their way. But even at this point, an enterprise policy is already at play – the fact that these services are even visible means I – the logged in user – have been implicitly entitled to them as a unique user or as part of a larger group. Infrastructure is totally abstracted. vRA doesn’t manage resources directly…that is left to the endpoint’s platform manager (e.g. vCenter, EC2, Azure, VIO, etc). Instead, vRA consumes the resources and makes them available to apps as a federated fabric.
Once the desired service is requested from the catalog, the request can be handed off for governance, where an approval policy may be triggered – or not – based on a set of criteria. Once approved, vRA goes off and does it’s thing – integrating with perhaps dozens of external services, wrapping them around each application being provisioned, and finally sending the consumer a notification once the deed is done.
But before we deliver an app, it needs to be designed in vRA’s unified design canvas (also known as the converged blueprint designer). Here, the application architect can chose from a library of component categories, such as Machine Type, Software Components, Containers, XaaS and, most importantly for the rest of this post, a set of out-of-the-box Networking & Security services. I’ll drill into those gems in a moment…
Just a quick, but very relevant, side note here…once designed in the canvas, the blueprint can be exported into YAML format and consumed as Infrastructure as code. This code can be shared for collaboration, modified, or incorporated into existing dev process, then reimported as a new version of the app. The code includes the configuration details of all the blueprint’s components, including the networking and security spec.
Video: Application Authoring in vRA’s Unified Designer
Integrating vRealize Automation with NSX is as straight-forward as entering the NSX manager URL and credentials and associating it with an available vSphere (vCenter) endpoint. vRA then runs a data collection and sets the stage for consumption. In vRA 7.3, this integration is native, leveraging the NSX REST API directly (previous versions depended on the vRealize Orchestrator plugin). Once the basics are configured, wrapping apps with NSX services is a matter of dragging and dropping them onto the canvas and [virtually] wiring it all together.
Target Use Cases
Automation for Network Operations
Operating a large organization usually involves thousands of devices focused on connectivity. Current operational practices have become archaic, consisting of manual, error-prone processes and efficiency drains. These environments are designed for static environments, not the fluid cloud environments of today. vRA helps simplify network operations by streamlining the provisioning and management of services such as load balancing, routing, and firewalls into enterprise environments. And they are all policy-based and bound to the application throughout it’s lifecycle. That means the services are provisioned with the app…and retire with the app.
Automation for Security Operations
For security operations, consistently automating the configuration and enforcement of firewall policies, app isolation, or entire on-demand networks will ensure applications are as secure as they need to be while still providing the flexibility of dynamically modifying those policies throughout an applications lifecycle stages.
Automation for DevOps
DevOps teams have similar challenges – or worse. Developers typically need direct access to infrastructure, preferably through the API layer. Fortunately, vRA and NSX provide a robust API that enables programmatic management of compute, network, and storage services. Additionally, vRA can manage the lifecycle of each iteration of a common application and provide unique networking and security services at each stage, eventually promoting one into production and decommissioning the others.
Cloud Operational Model
Delivering cookie-cutter applications can be trivial – build a template or image, configure it’s resources and dependencies, publish and deploy. But how often is that really the case? In reality, the fundamentals may be the same but each app will likely need it’s own set of policies and services, unique infrastructure placement, perhaps even a unique set of networking and security services. These factors can vary between use cases, the development lifecycle stage, or the environment it is deployed to. This process becomes exponentially more complex when you consider the people factor — who does what? when do they do it? how do they do it?
Enabling automation of network and security services doesn’t require a major overhaul of individual roles and responsibilities. Nor does it assume existing processes will be circumvented. It does, however, provide a means of driving efficiency (and accuracy) across all the roles that contribute to the cause…
- The Network Admin defines: Initial network configuration in NSX External Networks and Network Profiles in vRA
- The Security Admin defines in NSX: Distributed Firewall Rules Security Groups / Policies / Tags
- The Cloud Architect builds Blueprints: Blueprints include NSX Networks, Security components, Load Balancers, VMs and Apps
- The Cloud Architect also publishes Blueprints Cloud Consumer deploy applications: End-to-end provisioning: networks, NAT rules, security and LB configured at deployment
- The Cloud Consumer…consumes, over and over again
- Rinse and repeat
One of the objectives here is to reduce the number of revisions or manual configurations during app provisioning. Instead, the app and all it’s network and security services exist as a blueprint. At provisioning time, vRA automates backend NSX services – as defined by a set of enterprise policies – to dynamically deliver the services needed by the application. And it does that across any number of environments. Then…rinse and repeat.
Video: vRA + NSX Delivering App-Centric Networking and Security
Consider the vast benefits of vRealize Automation and NSX, working together to deliver application-centric network and security services in ways never before possible. Consider how these technologies can help modernize IT services, streamlining one of the most complex and error-prone components of the data center. It’s no wonder vRA and NSX are #BetterTogether.
Let this introduction absorb for a bit and stay tuned for the next post, which will dive much deeper into the many NSX services available within vRA.
++++
virtualjad
