Self-service and cloud automation are essential to DevOps or digital transformations. Organizations are finding they can no longer wait to get access to infrastructure to test and run their applications, services or third-party components. 

The problem is that not all self-service approaches are created equal, and the path to take depends on an organization’s needs and available skills, according to Maya Ber Lerner, chief technology officer at Quali, a cloud automation platform provider.

“Everything we automate can be pretty dangerous or risky and can cause some damage to the business,” she said in a webinar on SD Times. “It is like knowing all the words of the language, but you don’t know how to compose a meaningful sentence because if you want to use it correctly, it is more than just having good software architecture. You actually need to make sure you are not making any cloud mistakes and you need to have good architecture and you need to make sure you are not creating any risks.”

RELATED CONTENT: Getting it right: Self-service in cloud automation

“Making sure that developers don’t waste time on building a self-service platform and… they can focus on developing features that we care about… is something that we should all remember when we’re making these choices,” she added. 

According to Ber Lerner, the top four common self-service approaches are:

  • Extreme risk averse: This is the traditional approach where you want access to cloud services, you open a ticket and you have an IT Ops team that writes the resources or environments for you. Ideally, there is a team of cloud experts that fulfills the request and adds their expertise in to make sure it is secure and cost effective. “I call this approach extreme risk averse because it really gives you the best control that you can have on things like cost, security and compliance,” said Ber Lerner. “The chances of losing control or misplacing resources or not being able to audit are really low.” The problem in this approach is while you have confidence to use the cloud, it creates a bottleneck in the user experience. The end users lose autonomy, and the time it takes to get the necessary resources can be days or weeks because you fill out a ticket, someone else reviews it and then the provisioning happens, she explained. This approach works best for non-DevOps use cases with infrastructure that is in high-risk environments. 
  • Control first: In this approach, you have a platform dedicated to cloud management instead of a general IP tool like a ticketing system. The dedicated tool keeps an inventory of resources so users know what is happening at any given time, and policies are defined to help control those resources. “I think the great progress here, compared to approach number one, is that they really can expose this catalog of templates or resources to the end users. And that gives end users more autonomy than they have in approach one, which was nothing,” said Ber Lerner. The time it takes to get infrastructure could be just minutes if the template is already created, but if the template doesn’t exist then it could take longer. If you need new templates frequently, or need to make changes frequently, this approach is problematic because users are going to lose patience. Ber Lerner explained this approach is best for non-DevOps use cases that don’t have frequently changing templates. 
  • Speed first: With this approach, users get speed and innovation first by utilizing infrastructure as code. Ber Lerner explained it is a trust-based model where you give development teams the credentials for a cloud account or a sub account and that’s it. This approach only really works for coders, and could cause pain for developers who don’t want to be responsible for things like security, compliance or maintenance. “This approach is really suitable for small teams or internal low-risk applications where you don’t have special compliance requirements and don’t need to scale the operation in the visible future. You’re just trying to do something fast and very cheap,” said Ber Lerner. 
  • Scale oriented: This approach gives you on-demand access to templates within minutes, or can take minutes to hours to build a new template or building box. The risk here is you need to have the right structure to bring non-coders and developers together, and have people understand cloud and automation. That means people have to talk to one another and collaborate, according to Ber Lerner. The best use cases for this approach are DevOps initiatives where there is a good understanding of applications and services, or multiple teams that need to scale. 

“You need to start with identifying your current approach and the needs. What is the cloud use case and what are the ways that people get access to the cloud today. How do we provide them with the service, who are really the end users and what do they need. Then, when you do that, you can start thinking and choosing the right strategy for you depending on the type of company and how you’re using cloud,’ Ber Lerner said.