In my last post, I talked about how networking from the bottom up helped us reach success when we built the SHI Cloud. In the second part of our “Lessons Learned” series, I want to stress the importance of simplicity and attention to detail.
Lesson #2: Keep it simple
Customers want the SHI Cloud to provide a secure networking model, world-class virtual infrastructure, and appropriate security controls, all backed by a well-designed operations team with a resilient data center of the highest quality. After that, they want us to get out of the way.
Unfortunately, not all cloud providers do this. Amazon, for instance, has developed their own constructs for cloud computing — their own naming conventions, models, and ways of creating configurations pre-packaged for customers. So application teams, development teams, QA teams, and other functional users of IT infrastructure would have to learn to do things differently if they went with the Amazon cloud.
Customers told us they wanted a cloud that fit with their current processes and operations. The SHI Cloud was built so that customers won’t have to change anything they’re already doing. They have virtual machines running applications or hosting development environments, and they do everything in very specific ways. They’ve invested a lot in their own design, and their own view of computing.
We simply allow them to take those virtual machines, convert them to an open-standard format, import them into our cloud, and turn them on. And as I wrote in my last post, those machines exist on their network, accessible from an IP address on their network. The end result is that they have the exact same thing that they had running before on their network, only now it’s hosted in our cloud and they’re just paying for the infrastructure on a monthly basis based on how much they use. It’s very transformative, without forcing everybody to learn a new way of doing business.
Lesson #3: The details matter
We learned that we needed to share a lot of information about how our cloud is engineered — storage, servers, virtualization, networking, security, automation, and so on. If our charter is to provide IT a production-grade infrastructure with the promise of cloud, then we must respect the people who are doing the architectural work at the customer level for their application. After all, we are not just a service provider; we are an extension of their organization.
We are their virtual internal infrastructure team, and we are providing more than just infrastructure. We are operational people that monitor and protect their investments. We are the architects that can tell them how the cloud is designed, and how something will actually work — because not everything works well in the cloud.
Customers need to know what our connectivity model is, from the perimeter of their data center, all the way through the carriers, into the SHI data centers. Should a customer come across MPLS, a VPN, or a high-speed private line through a DWDM ring? Do they need redundant connectivity? What makes the most sense for their workloads? If there’s a financial conversation to have, we can advise the customer on the different carrier options.
Customers also need to know:
- The redundant design of every aspect of our computers, network, and physical infrastructure in our centers to protect against disruption of service.
- The design and specs of the hardware we have chosen to run their virtual machines.
- How we balance workloads in our center to optimize performance and avoid disruptions during maintenance.
- The internal bandwidth throughout our data center to ensure there are no bottlenecks.
- The security model we have put in place and how we monitor for vulnerabilities.
- How they can create custom network architectures in our cloud that support their unique application requirements.
- And the list goes on …
How many cloud providers are currently willing to do a detailed review of their architecture with a customer? Out of respect for customers, the answer should be all of them, but that is far from the case. Over the past year, as we have shared these details with our customers, we have been able to foster relationships built on trust and transparency, which has allowed our customers to make informed decisions on how to use our cloud with confidence.
This approach has brought recognition of SHI in the industry. For example, we continue to work with the Internet2 Consortium and were selected as their first infrastructure as a service (IaaS) provider. We are working with top-tier research universities and their high-performance computing teams, which has helped to shape our next generation offering to support the HPC community.
From large enterprise customers to SMB customers, we have engaged in detailed conversations that continue to improve our offering. There’s no way we could have anticipated all of this when we started the SHI Cloud a year ago, but working out the details with our customers has opened new doors for both us and them.
During the next post in this series, I’ll focus on the business model that worked for the SHI Cloud, and the integral role transformative ease of use has played in the success of our cloud.