Home > Blogs > VMware Operations Transformation Services > Tag Archives: #CloudOpsChat

Tag Archives: #CloudOpsChat

Task Automation Vs. Process Automation – Highlights from #CloudOpsChat

After a successful automation-themed #CloudOpsChat in September, we decided to take a deeper dive into automation for this month’s edition, discussing “Task Automation Vs. Process Automation.” Thanks to everyone who participated, and thank you especially to Rich Pleasants (@CloudOpsVoice), Business Solutions Architect and Operations Lead for Accelerate Advisory Services at VMware, for co-hosting!

To begin the chat, we asked: “What IT tasks or processes has your company successfully automated?”

@Andrea_Mauro jumped right in, asking how automation compares to tasks? @kurtmilne offered VMware’s take, saying “VMware IT has fully automated provisioning of complex workloads on private cloud,” and clarified that the most complex workloads were “Oracle ERP with web portals, and over 80 blueprints.” @venkatgvm also elaborated on VMware’s automation story: “VMware instance provisioning had over 20 major steps, each of them were executed by siloed teams.”

Co-host @CloudOpsVoice took the question further, asking, “Are people automating day to day maintenance activities or actual steps in the process?”

@vHamburger gave his advice on where to begin with automation, saying “[day-to-day automation] is a good starting point. Nominate your top 10 time-consuming tasks for automation.” @Andrea_Mauro replied, suggesting that “task automation is more for repeatable operations and day by day [tasks].” He followed up by offering a definition of process automation: “Process automation could be more related to organization level and blueprint usage.” @kurtmilne also chimed in with business-related definitions of task and process automation: “Task automation math includes cost/time of single task vs. developing automation capability…Process automation math includes business benefit of overall improved agility, service quality – as well as cost.” @CloudOpsVoice broke his definition of automation into three parts: “day-to-day, build and run.”

@CloudOpsVoice next asked, “What technique do you use primarily for automation? Policy, orchestration or scripting? How do App blueprints impact it?”

@kurtmilne noted the value of blueprints and scripting: “Blueprints and scripting allow app provisioning automation – not just VM provisioning.” @thinkingvirtual also offered sound advice on how to select what to automate at your company: “Always make sure your automation efforts provide real value. Don’t automate for automation’s sake.” Elaborating on this, @kurtmilne discussed the value of automation, stating that automation’s “real value” is “ideally measured in business outcomes, and not IT efficiency.” @vHamburger also warned against bottlenecks preventing automation: “every enhancement after your bottleneck is not efficient – know your bottlenecks!”

@vHamburger went on to mention task workflow: “Clean task workflow with documented steps is always preferred over scripts,” he suggested, because it’s “easier and repeatable for new admins.” @Andrea_Mauro countered by saying that sometimes a “‘quick and dirty’ solution could be good enough,” to which @vHamburger replied, “In my experience ‘quick and dirty’ always leads to fire fighting ;).” @kurtmilne then vouched for “leaning out” a process: “‘Leaning out’ an IT process is good. But sometimes it’s better to use automation to eliminate tasks vs. automate tasks,” he wrote. @thinkingvirtual also noted how important communication is to successful automation: “Often forgotten: keep your business in the loop. Show back the value continuously to broaden the relationship.”

@AngeloLuciani kept things moving by asking, “Do you pick a tool to fit the process or a process to fit the tool?”

@JonathanFrappier enthusiastically went with the latter: “Process to fit the tool! Processes can change, tools have to live on until more budget is approved!” @kurtmilne added, “Tool/process construct doesn’t make sense with full automation. You can do things with automation you can’t do with manual tasks: For example, you don’t figure out manual horizontal scaling process in cloud – then look for tool to automate.”

#CloudOpsChat ended with one last great tip (and a nod to VMworld!) from @thinkingvirtual: “Automation skills are a huge career opportunity. Don’t avoid automation, defy convention.”

Thanks again to everybody who participated in this latest #CloudOpsChat, and stay tuned for details of our next meet up. If you have suggestions for future #CloudOpsChat topics, let us know in the comments.

For more resources on automation, check out the following CloudOps blog posts below:

In the meantime, feel free to tweet us at @VMwareCloudOps with questions or feedback, and join the conversation by using the #CloudOps and #SDDC hashtags. For more from Rich Pleasants, head over to the VMware Accelerate blog.

Task Automation vs. Process Automation: Join Us For #CloudOpsChat 11/13!

Here at VMware, we’re always talking about automation: Venkat Gopalikrishan detailed his success after automating the provisioning of business-critical application stacks, and Paul Chapman introduced VMware’s IT transformation story by highlighting the importance of automation and change management.

We saw some fantastic insight on automation from many of you during our last #CloudOpsChat and wanted continue the conversation. For this month’s #CloudOpsChat, we’re specifically focusing on next steps in automation by asking the following questions: What has your company successfully automated? Do you focus on task automation, process automation, or both?

Join us on Wednesday, November 13th at 11am PT to discuss task vs. process automation with your CloudOps peers. Hosting the chat is CloudOps expert Rich Pleasants, Business Solutions Architect and Operations Lead for Accelerate Advisory Services at VMware.

During the chat, we’ll discuss:

  • What business tasks or processes has your company successfully automated?
  • When discussing automation, how do you determine whether you should automate a task vs. a process?
  • Do you have people in your company whose primary role is automation?
  • What technique do you use primarily for automation? Policy, orchestration or scripting?
  • How does the blueprint concept impact your automation workflow (scripting, orchestration)?

Here’s how to participate in #CloudOpsChat:

  • Follow the #CloudOpsChat hashtag (via Twubs.com, Tchat.io, TweetDeck, or another Twitter client) and watch the real-time stream.
  • On Wednesday, November 13th at 11am PST, @VMwareCloudOps will pose a few questions using the #CloudOpsChat hashtag to get the conversation rolling.
  • Tag your tweets with the #CloudOpsChat hashtag. @reply other participants and react to their questions, comments, thoughts via #CloudOpsChat. Engage with each other!
  • #CloudOpsChat should last about an hour.

In the meantime, RSVP to the event and feel free to tweet at us at @VMwareCloudOps with any questions you may have! For even more on automation, check out Rich Pleasants’ latest blog post for VMware Accelerate where he discusses “Intelligent Automation.”

We look forward to seeing you in the stream!

To Automate or Not to Automate? – Highlights from #CloudOpsChat

Last week, we held another successful #CloudOpsChat, this time asking: “To Automate or Not to Automate?” Thank you to everyone who participated in the lively conversation, and especially to our two co-hosts, Cloud Operations Architects Andy Troup (@HarrowAndy) and David Crane (@DaveJCrane)!

To start things off, we asked, “How do you define automation?”

Our co-hosts jumped in first, with @HarrowAndy stating, “automation = stop doing repeatable tasks,” and @DaveJCrane remarking on how he asked the same question during a group discussion at VMworld and received 50 different answers from 50 different people in the room! In addition, the notion that automation implies the removal of manual work was a prominent theme, with @Seemaj, @AngeloLuciani, @tcrawford and @KongYang agreeing that automation means less, or no, human intervention (see Pierre Moncassin’s take on that here).

Next, the conversation moved on to the importance of defining automation within the context of your business.

@DaveJCrane began by adding a layer to the definition, suggesting that it is “important to consider the definition of automation in context of the business environment, not just process focus.” @tcrawford agreed with David, specifying a difference between the what/why of automation, as well as the how/when. @HarrowAndy built upon @tcrawford’s response, adding that there must always be a benefit to what you’re automating, and that there is “no point automating something you only do infrequently.”

@Seemaj then brought up the cost of automation, agreeing with @tcrawford that: “There is a cost to automation, and the business drives those decisions.”

@AngeloLuciani stated that “automation drives business value,” and @tcrawford stirred the pot, replying “sometimes it can, not always.” @HarrowAndy then brought up the importance of weighing automation’s benefits with its costs, with @KongYang, @AngeloLuciani and @Seemaj adding that two of the biggest benefits to automation are limiting human mistakes and delivering services faster. @Gnowell1 emphasized automation’s goal of promoting reliable service delivery, saying “time consuming, complex tasks should also be considered for automation.”

After that, @KalraRohan asked, “What’s driving everyone to move towards automation?”

@VmwDavidH immediately offered VMware’s use case for automation: “For us, we have cut our dev environment provisioning time down from weeks to hours.” @Seemaj noted business agility as her main reason, with @AngeloLuciani saying that automation is a “building block” towards the software-defined datacenter (SDDC). @DaveJCrane agreed, adding that “[automation] is always good to implement as part of a larger ops transformation.”

@KalraRohan then asked, “What are the operational impacts of automation? What are best practices?”

@HarrowAndy, @VmwDavidH and @AngeloLuciani all agreed that a set of orchestration tools was essential in driving the success of automation. @GNowell1 suggested a key benefit that automation provides to a business: “SDDC automation promotes Ops standards. Administrators spend more time on higher level responsibilities.” And @DaveJCrane elaborated further on automation’s ability to shift ops’ focus: “Automating allows you to put more emphasis on the workflow/approval process.”

To close out this #CloudOpsChat, @HarrowAndy asked: “So what have you all automated? Is it just provisioning activities, or are there other things?”

@AngeloLuciani and @Gnowell1 had both started with provisioning and said they were looking for the next step in automation. @CloudOpsVoice stated that provisioning was a great start and great use-case for the ‘run’ side of automation, with @tcrawford adding “iterative automation is all about value.” He continued by saying that knowing what to automate next comes with “experience, and asking questions.” @Seemaj agreed, and emphasized that automation touches all aspects of a company: “Automation is not just about provisioning/tools/scripts…and it does not always have measurable outcomes. Sometimes benefits are soft benefits, e.g. improved user experience.”

Our #CloudOpsChat wrapped up with a positive outlook on the future of automation, with @AngeloLuciani tweeting “automation will be a major skill for next gen IT staff.” As automation progresses, companies will experience “less firefighting in operations and more time spent on working with the business,” suggested co-host @HarrowAndy.

Thanks again to everybody who participated in this latest #CloudOpsChat, and stay tuned for details of our next #CloudOpsChat!

In the meantime, feel free to tweet us at @VMwareCloudOps with questions or feedback, and join the conversation by using the #CloudOps and #SDDC hashtags.

To Automate, or Not to Automate? Join Us For #CloudOpsChat 9/18!

We talk about automation regularly here on the CloudOps blog – Kurt Milne looked into the economics of task and service automation, Andy Troup broke down the automation Scripting, Orchestration and Technology Love Triangle, and, more recently, Pierre Moncassin discussed how automation doesn’t always mean removing the human element from your workflows. Automation, of course,  also continues to be a hot topic for our customers.

For our next #CloudOpsChat on Wednesday, September 18th at 11am PST, we’d like to invite our CloudOps audience to keep the conversation going, discussing: “To Automate, or Not to Automate? – considerations and best practices for IT admins looking to take advantage of the benefits of automation in a smart but effective way.”

Co-hosting the chat will be our very own CloudOps bloggers Andy Troup and David Crane, both Cloud Operations Architects at VMware.

During the chat, we’ll discuss:

  • What approach have you taken to identify suitable processes to automate?
  • What process areas have you started automating?
  • What technique is primarily used for your automation? Policy, orchestration or scripting?
  • What makes a process a good candidate for automation?
  • What challenges has your organization faced when approaching automation?
  • What business processes have you successfully automated in your organization?

Here’s how to participate in #CloudOpsChat:

  • Follow the #CloudOpsChat hashtag (via Twubs.comTchat.io, TweetDeck, or another Twitter client) and watch the real-time stream.
  • On Wednesday, September 18th at 11am PST@VMwareCloudOps will pose a few questions using the #CloudOpsChat hashtag to get the conversation rolling.
  • Tag your tweets with the #CloudOpsChat hashtag. @reply other participants and react to their questions, comments, thoughts via #CloudOpsChat. Engage with each other!
  • #CloudOpsChat should last about an hour.

In the meantime, RSVP to our #CloudOpsChat and feel free to tweet at us at @VMwareCloudOps with any questions you may have. We look forward to seeing you in the stream!

Reaching Common Ground When Defining Services – Highlights from #CloudOpsChat

On May 30th, we hosted our monthly #CloudOpsChat on “Reaching Common Ground When Defining Services.” Thanks to all who participated for making it an informative and engaging conversation. We would also like to thank John Dixon (@GreenPagesIT) from GreenPages and Khalid Hakim from VMware (@KhalidHakim47) for co-hosting the chat with us.

To kick off the chat we asked, “What exactly is an IT service?”

Our co-host @KhalidHakim47 suggested they are intangible by nature, unlike products. Our other co-host, @GreenPagesIT, gave the textbook answer: IT services are an asset worthy of investment. He added that an application alone is not an IT service. @kurtmilne defined an IT service as something designed to deliver something to someone in a form or function that meets their need. @AngeloLuciani said that an IT service delivers a business outcome. @KongYang saw it as a bounded deliverable that states which things are being provided by whom and the support that’s to be rendered when things fail.

Next we asked, “Why should you define services in the first place?” Followed by, “What are the benefits of doing so for your users?”

@KhalidHakim47 started off by saying that you cannot claim you manage services until they are defined in the first place. @kurtmilne said service definitions set expectations, which are a key dependency for creating satisfied users. @jfrappier added to Khalid’s point, saying that you also can’t control your public cloud vendors, so as a consumer you need clear definitions. Khalid went on to say that without a service definition, the boundaries may be loose between IT deliverables – setting expectations becomes much clearer when you address a well-defined service. @harrowandy chipped in saying the definition of services helps to make sure that the customer and IT are expecting the same outcome, with which @alamo_jose agreed. Co-host @GreenPagesIT said IT services help to organize people around a delivery objective instead of a technology objective.

We then noted that multiple roles contribute to specifying a service definition and asked, “What roles are involved in defining each service?”

@KhalidHakim47 argued that the driving and accountable role for defining a service is the service owner/manager, but it is not a one-man show. According to Khalid, @CloudOpsVoice and @alamo_jose, some of the key roles involved include the Business Unit Liaison, IT Service Manager, Consumer Relationship Manager, Portfolio/Catalog Manager and Architect, the Service Liaison Manager and Service Catalog Manager. Co-host @GreenpagesIT explained that at first pass, it’s a small group that defines the service, but eventually more parties become involved as you roll into CSI. @harrowandy said the service must have an owner who takes the service from cradle to grave and from initiation to retirement.

We then asked our audience, “Are there recommended approaches to getting multiple groups of users to reach consensus in their service definition?”

@AngeloLuciani explained that groups need to be driven by the business strategy and outcomes. @harrowandy agreed, adding that if groups don’t know the business strategy, how can IT provide them what they want? Co-host @KhalidHakim47 suggested that during the service definition planning phase, all roles that are expected should be looped into the exercise with clear goals and outcomes. @KongYang made a great analogy, saying too many chefs in the kitchen will kill the service – instead, we should look to have one chef for one service, a point with which many of our participants agreed.

Next, co-host @GreenPagesIT wondered: “Are there recommended approaches to balancing the needs of both IT and service consumers?”

@kurtmilne said that IT can deliver fast and cheap if standardized, but slow and expensive if customized. Agreeing,  @KhalidHakim47 said there’s a balancing act between packaging/standardizing and customizing. @harrowandy suggested using the “80/20” rule: You can get 80% of what you want now, or wait a certain number of weeks for the remaining 20%. Kurt also brought up the fact that IT service standardization gives users more flexibility and business process level, with which @alamo_jose agreed, adding that IT must help the business understand that reality. Co-host @KhalidHakim47 noted that standardization drives efficiency, but allowing more service levels gives more freedom as well. Co-host @GreenPagesIT added that requirements should be negotiated during the service definition and not specs.

Switching gears, we then asked “What service components do you think should be included in a service definition?”

@kurtmilne stated that pricing services is key – pricing requires accurate costing, and costing requires clear service definition, thus making the whole process come full circle. @alamo_jose added that ownership, SLA/OLA, a clear definition, features, cost and related services should all be included. Co-host @GreenPagesIT said that knowledge of how to access the service is a necessary service component, as well as hours of operation.

To round off the chat we closed with the question, “What do you do after you define services? What are the next steps?”

For @jfrappier, the answer was, “IT needs to define, then document and automate.” @alamo_jose chipped in, saying that once the service is defined, it should be published in the Service Catalog, with @AngeloLuciani adding that IT also needs to educate and communicate on how to leverage the services. @ckulchar, however, had a very different answer – once services are defined and delivered, he suggested, users should drink beer and celebrate!

Thanks again to everybody who participated in our #CloudOpsChat, and stay tuned details around our next #CloudOpsChat!

Feel free to tweet us at @VMwareCloudOps with any questions or feedback, and join the conversation by using the #CloudOps and #SDDC hashtags.

Reaching Common Ground When Defining Services – Join Us For #CloudOpsChat!

An optimized service definition process can make or break the success of hybrid clouds or Software-Defined Data Centers (SDDC). But even if you have tools and processes in place to enable automated provisioning, you still need key stakeholder agreement on the makeup of standard services and resource configurations.

  • Standardized services need to meet the needs of those who request and consume the services.  But they also need to make sense to those in IT responsible for both automation that delivers the services and ongoing support.
  • Standardization helps increase flexibility at the business process level. But rigid service definitions can also inhibit those who both consume and deliver the services.

So how can you meet the needs of multiple groups and find common ground when it comes to defining services?

Find out by joining our next #CloudOpsChat on “Reaching Common Ground When Defining Services” taking place on Thursday, May 30th at 11am PT.

The event will be co-hosted by two CloudOps pros who have helped multiple VMware customers reach common ground:

  • John Dixon, Consulting Architect at GreenPages (see John’s posts on GreenPages Journey to the Cloud blog)
  • Khalid Hakim, Cloud Operations Architect at VMware

During the chat, we will answer the tough questions:

  • What service components should be included in a standard service definition?
  • What components can be flexible for modification around the edges?
  • Are there obvious points of abstraction that help balance standardization and flexibility?
  • Are there recommended approaches to getting multiple groups of users to reach consensus?
  • Are there recommended approaches to balancing the needs of both IT and service consumers?
  • What happens if key stakeholders don’t reach consensus?

Here’s how to participate in #CloudOpsChat:

  • Follow the #CloudOpsChat hashtag (via TweetChatTweetGrid, TweetDeck, or another Twitter client) and watch the real-time stream.
  • On Thursday, May 30th at 11am, @VMwareCloudOps will pose a few questions using the #CloudOpsChat hashtag to get the conversation rolling.
  • Tag your tweets with the #CloudOpsChat hashtag. @reply other participants and react to their questions, comments, thoughts via #CloudOpsChat. Engage with each other!
  • #CloudOpsChat should last about an hour.

In the meantime, feel free to tweet at us at @VMwareCloudOps with any questions you may have. We look forward to seeing you in the stream!

The Changing Role of the IT Admin – Highlights from #CloudOpsChat

Last Thursday, we hosted our inaugural #CloudOpsChat on “The Changing Role of the IT Admin.” Special thanks to everyone who participated for making it an informational and thought-provoking conversation. We also wanted to thank Nigel Kersten (@NigelKersten) and Andrea Mauro (@Andrea_Mauro) for co-hosting the chat with us.

We kick-started #CloudOpsChat with the question, “Is increasing automation and virtualization good or bad for your career?”

Our co-host @Andrea_Mauro was the first to answer, making the point that IT is always evolving and you can’t realistically stay static in knowledge and skills. @KurtMilne agreed with Andrea, adding that more standardization and automation will help to foster the Industrial IT era and move away from the “artisanal” IT era, which is good for IT careers. Co-host @NigelKersten emphasized that IT needs to automate or prepare to be in an evolutionary dead-end in ops roles, adding that the business demands of today are too great not to do so. @andrewsmhay echoed Nigel’s thoughts, saying that the increase in automation and virtualization is good, taking a “survival of the fittest” standpoint – IT needs to evolve or perish. @ckulchar added to both Kurt and Andrea’s points, noting that IT needs to shift the focus to enabling app teams to effectively use cloud and not just port existing apps. @jakerobinson also joined the conversation, saying that increasing automation and virtualization is necessary in order to balance IT cost with capability.

With the discussion in full swing, we took to our next question: “How exactly does increasing automation change your job?”

@NigelKersten stated that increasing automation changes many roles, not just IT operations. @KurtMilne chipped in as well, saying that an increase in automation frees up your time to work on things that really matter, providing more value to your business. @jakerobinson had a similar opinion, explaining that automation eliminates human error, which means less unplanned work that he would have to take care of at a later time. @randwacker added that automation also allows businesses to move faster and be more innovative, which is a key value of Infrastructure-as-a-Service and cloud. @lamw offered a great analogy in answering this question, saying that not automating your infrastructure is like ignoring the existence of the assembly line in manufacturing.

We then asked our audience, “Do you think abstraction and better tools decrease the need for deep expertise?”

@DuncanYB thought so, but also added that abstraction does not result in a decrease of deep expertise, as you still need to build a strong foundation. @randwacker agreed with Duncan, as long as the tools package expertise with it. @KurtMilne added that automation and abstraction will definitely reduce the need for everyone to read 2-inch thick manuals. He made a point to say that someone will still need to read the manual in order to set up the automation, but from there others will be able to use the automation without the reading. @wholmes noted that deep expertise is needed in the development lifecycle of a solution, regardless of abstraction or not. He added that abstractions lessen the need for deep expertise in the operational phase of a solution. Both @NigelKersten and @KurtMilne agreed with @wholmes, saying that automation pushes expertise earlier in the service lifecycle.

Next, we asked our participants, “Do you think today’s cloud administrators need programming skills?”

@randwacker answered yes – cloud admins do need programming skills, but that’s quickly getting packaged. @DuncanYB hoped that they would not need programming skills, as he thought scripting was already difficult enough as it is. @NigelKersten pointed out to Duncan that programming could be easier than scripting, as better tools and interfaces make it easier to use the work of others. @jakerobinson said that cloud admins definitely need software development skills – from consuming APIs, as well as understanding agile methods. @ckulchar agreed, and added if cloud admins don’t learn the fundamentals of development, developers will learn cloud admins’ skills, resulting in a need to differentiate themselves. @wholmes said he hoped that cloud admins wouldn’t be required to have programming skills, but it all depends on the cloud.

From there, we asked participants, “Is PowerCLI better than your average scripting language?”

Both @lamw and @wholmes had similar viewpoints, saying that it may or may not be better, but that it depends on the background, which our co-host @Andrea_Mauro agreed with. @lamw chipped in that you have to use the right tool for the right job, and that the key is: if there is an API, you can automate it using a variety of tools – an idea that both @virtualirfan and @jakerobinson supported.

Staying with tools we then asked: “What are the advantages of managing compute, storage and network resources from a single tool?” 

Our co-host @Andrea_Mauro answered that one of the main advantages would be having complete control of all the resources. @NigelKersten added that network/storage configuration being attached to services allows for easier workload migration. @KurtMilne asked if it is reasonable to expect a single admin to effectively manage compute, storage and network, to which @wholmes said yes, but only to provision. If it were end-to-end, it would not be reasonable. However, @kix1979 said that in the current IT environment, no single tool can manage compute, storage and network resources.

We concluded our discussion by asking, “What do you think is the one skill all IT admins should learn this quarter?”

@lamw offered a short and sweet answer: Automation. @maishsk said that IT admins should learn Puppet/Chef, or even both. Co-host @Andrea_Mauro echoed William’s sentiment by saying that they should learn automation with good framework, which @wholmes and @KurtMilne agreed with. Both @kix1979 and @jakerobinson believed it would be important for IT to learn the business value and costs of running IT/services.

Thanks again to everybody who listened or participated in our #CloudOpsChat, and stay tuned details around our next #CloudOpsChat! Feel free to tweet us at @VMwareCloudOps with any questions or feedback, and join the conversation by using the #CloudOps and #SDDC hashtags.