5 simple techniques to achieve your cloud automation goals
As cloud adoption accelerates so does the need to automate the pipeline that integrates such cloud workloads with services and 3rd party platforms. Techniques outlined below are gathered from my experience helping large scale customers implement a range of Hybrid Cloud architectures, including VMware, AWS, and the most recent offering of VMC on AWS, which can be applied to other cloud platforms just as readily. These techniques are geared towards helping Cloud Architects focus their automation, coordinate the multiple teams involved in delivery, and achieve success in getting the full workload lifecycle operational at scale.
1: Start with the end first.
Begin with the end goal in mind, who will use your platform, what are their expectations, and finally how will they use your platform (UI/API). Too often I’ve seen large teams build cloud platforms that either replicate a competitor or come up with something on their own, only speaking with the end user sporadically to validate the end product. Don’t do that. Start with the end user first, for example a developer who needs a MongoDB, Express, Angular, NodeJS stack to build a specific version of an application. Keep that “MEAN” stack in mind as you build the pipeline of automation needed to go from request to a deployed MEAN stack with code loaded for testing.
2: Be in a “Show me” state of mind.
Customers always want tangible outcomes; for example API stubs that show how to use the platform, UI that shows how to self-service works, or how monitoring and charge-back will calculate the per-workload cost, something tangible that you can show and iterate over. I setup a recurring schedule to keep showing customers what works end-to-end, as you build and integrate more in the pipeline the customer will be able to see your progress towards the end goal. The “Show me” state of mind will also help your customers see what is delivered, spotlighting assumptions or ideas they had about the deliverable, and giving you an opportunity to address them early in the process. In the absence of deliverable code, a well put together sequence diagram can help tremendously, start with that at least, such that you can solidify the first objective, getting the End Product crystalized and developing along that sequence pipeline to deliver the desired platform, a MEAN stack in our case.
3: Keep the automation pipeline simple and clean.
As you develop an automated to deliver the End Product, you will be integrating with 3rd party platforms, developers, and teams that are required to perform a task critical to building of a stable End Product capable of running in production. Approach the sequence pipeline with the needed integrations, grab some lunch and come back to see what in the pipeline you can simplify and clean up to achieve the End Product. For example, can the networking team pre-allocate you IP addresses within a Subnet on a VPC for AWS that you can consume for workloads, or can the OS team pre-build a few templates for you to quickly build out workloads and deploy on vCenter? Such simplifications can keep the pipeline clean of complicated interactions, which could destabilize your End Product. Stubbing out is a great way to keep the pipeline clean, this way you can build a stub showing proper integration scenarios, while the team or developer is building the actual automation behind the stub. You should not see any difference in the end-2-end sequence when the stubs are switched for actual working code, based on the interface you’ve defined. Stubbing and keeping the pipeline will also make it possible to quickly identify and resolve issues as they arise, for example when a Service Account refreshes and needs to be updated through out the pipeline.
4: Write cleaner code.
Writing clean code consistently is a key technique in achieving your cloud goals. You have to show what good looks like, balancing the optics of code reviews while helping developers with dirty code clean up. Often I’ll work with the customer to show what we use internally, from conventions, to abstractions, and where to store transient data in cache that methods and classes can share a state without too much complexity. Inconsistency and complexity take you further away from the shape the code needs to be in to achieve the End Product. This consistency and simplicity have to span the full lifecycle of your workloads, including request, configure, scale out/in, and retire. Additionally focus on consistency and simplicity will help clear distractions from business logic, and integrations required in automating the workloads fully. Holding regular code reviews within your sprints are essential, I’ve coupled them often with demos such that I can show you what the code is, and then show you what it does in a tangible form. For large code bases and distributed teams, those on review have to check-in and send review requests two business days prior to the review and demo, such that folks have a chance to review in-depth and we can have a constructive conversation about what the feature is and how the code does it, along with review changes, rather then checking if anyone has reviewed the code. Writing clean code that others can understand and learn from is also a great way to get good optics for your feature, and with peer-review cycles.
5: When in doubt go back to step 1.
There will be 100 distractions each day to take you away from producing the End Product required. From challenges in Automation API, to permissions on a shared folder, or getting IP/DNS from the Network layer….oh and meeting…meetings..and meetings. When you run into a distraction or a change, go back to step 1, and validate this new item fits into the End Product pipeline. I typically carry the end-2-end sequence pipeline with me to each interaction, such that it’s easy to refer back to what’s the End Product and how this integration, API, or the meeting is working towards the end goal. This also helps clear up process bugs, or assumptions on how automation would work from the developers involved within the pipeline.
Summary:
Building an automated cloud with integrations into multiple 3rd party platforms is enjoyable and can scale to support millions if not billions of workloads, if done with a consistent, clean, and scalable automation pipeline. Keeping the sequence of automations in this pipeline visible and clean along the process starts with the End in Mind first, serving that all important persona within the business world…The Customer. Having visibility of the end throughout the process will help you as you navigate the APIs, teams, and organizations needed to achieve the End Product. I hope you found this quick blog about a few of the techniques useful. Such techniques have helped achieve success at companies I regularly help architect and lead full-stack automation with, companies with large scale deployments in production; whose techniques can help you as well.