Clutch spoke with Lele Calò, Systems and Network Specialist at End Point, and Josh Williams, Database Specialist, about the best practices for utilizing cloud technologies – an important consideration for organizations making a shift to the Cloud.
Please describe your organization.
Lele: End Point is a software consultancy company based in New York City, which has been around for 21 years. We have 3 or 4 main areas of business, one of them being software development offered as a consulting service. We offer regular and internal software development. We have been involved in virtual reality projects, and we cover all the possible needs of our customers. Another area of our business focuses on Liquid Galaxy, which is a project that was created inside Google. We took a part of the development on our shoulders, offering support and installations. The project itself is open-source, so we offer third-party consultancy for customers who need it. They may not have the technical expertise to physically create an environment. Anyone interested can look it up at liquidgalaxy.endpoint.com. It consists of a semi-sphere set of monitors which allows for a 180-degree field-of-view. It's mostly used with Google Maps, but it can also be utilized within museums and exhibitions for different tasks.
Another of End Point’s focuses is hosting. We offer regular hosting consultancy, as well as database consultancy, which may or may not be included in the hosting services, depending on the client. We offer server maintenance, cloud system setup, as well as anything else that the hosting definition could entail in the broader sense.
What is your position?
L: I am the hosting team coordinator. I am based in Italy and have been working with End Point for 3 years.
Josh: I also work within the hosting team, and am involved in database administration.
What specific cloud technologies are you familiar with, and which vendors do you use regularly?
L: Within the last few years, we've had customers using Amazon Web Services [AWS], Rackspace, OVH Google Cloud, Linode, and DigitalOcean. We don't tend to force cloud usage on our customers, given that most of them are mid-sized businesses without the budget for a big cloud infrastructure, but we have had customers using cloud technologies, and we're glad to work with them.
What is the biggest business challenge that a company is able to overcome by utilizing cloud services?
J: The biggest business challenges that can be overcome through the cloud are usage profiles and load inconsistencies. If a load isn't consistent, being able to scale up and down is a big benefit. With a traditional infrastructure, a client will buy a bunch of servers, pay a big amount upfront, and that will be the sum of their resources. With the cloud, the infrastructure can be architected so that, as the load scales back, the amount of available systems and consumed resources can be reduced, with a reduced cost in the end. Clients can also scale up much faster than in a traditional infrastructure, where they'd be buying servers for more capacity. Normally, hardware would need to be ordered from a vendor, which comes with quite a bit of latency, compared to simply running an API call and deploying additional resources through Amazon Machine Images. This flexibility and ability to pivot is key to the cloud experience.
L: I agree that these are key points: molding a setup for high availability and scalability.
What recommendation would you make to organizations that are just now moving into cloud services?
L: Based on our experience, doing an all-in-one job is almost always painful and prone to some risks. If that's not absolutely mandatory, starting with little infrastructure tests and small steps will work better most of the time. Creating a parallel testing infrastructure, verifying that it is up to expectations, and moving components in a modular fashion is best. Another advantage of cloud systems is that they allow for many different self-enclosed containers interacting with each other in an easy way. If an application or infrastructure can be modularized, then each of those bits can be moved over time, which will lower the risks and enable the client to have more control and confidence in the infrastructure. One thing which we always encourage is for customers to have good knowledge over their infrastructure, meaning that engineers, administrators, and DevOps who know how to deal with the cloud are necessary. Dealing with a server is complex, but dealing with a cloud infrastructure is complex squared. It almost never is as easy as advertised. There are pitfalls and other elements which aren't seen from the surface.
J: Being able to divide services and move things in a piecemeal way is certainly the easiest route for any migration.
Could you discuss the cost of utilizing these technologies?
L: This varies based on what a company needs to do with its cloud infrastructure. We had a customer who needed some quick tests on a batch of processes, and didn't need all their virtual machines to be used during tests. There was a huge spike of resources which we could then get rid of. In that case, we could get the most benefit out of the pay-per-use approach. Otherwise, creating a cluster of servers would have cost us way more than what we used.
On the other hand, if a server is online 24/7, clients will end up paying more for a cloud provider. There are offers which allow users to ease costs, like Amazon EC2 Reserved Instances, which lower costs a little, but they don't really compare to other regular monthly payment providers. With the cloud, the customer pays for additional flexibility and features, so it wouldn't surprise me that they'll end up paying slightly more, depending on the scenario.
J: It's almost a case of what people are familiar with. If all that a company knows is a traditional infrastructure, then even if they're pushed to the cloud, they will have a tendency to engineer things so that they'll be running 24/7, which will be more expensive. Clients are then paying for flexibility, but they're not taking advantage of it. People jump too soon, without evaluating all of their options. If someone is in the position of architecting their infrastructure in order to take advantage of the cloud, they should, but not many people do it properly.
Is there a specific reason for using the platforms that you've chosen in the past?
L: In the case of AWS, is was mainly for their features. It was easier to do the tasks that we needed to do using AWS. It wouldn't have been impossible to do the same thing with another provider, but Amazon provided easier options. In other cases, it was a matter of cost/features. If we didn't need all the features offered by a provider, then we were better off with one that gave us similar or fewer features that cost less. This was the case with Rackspace. We've used it for some of our customers because it had a smaller cost on the monthly bill. For them, even a basic solution like Rackspace was good.
J: I'm not a big fan of AWS, but the number of building blocks that they have available impressed me. On the AWS product page there is a list of container and storage services, networking options, and many other building blocks. If all a customer is doing is spinning up a couple of virtual machines, they can certainly do that through the EC2 service, which may be ideal. One of the projects that I worked on involved spinning up a ton of services, around 128 at the highest level. We used them for a couple of hours for running some parallel tests, then shut them off. AWS provided a cost-effective way of doing this. We couldn't have done this anywhere else, even though we were only using base virtual machines. If there is a need for 24/7 operation, then a company like Linode would be more beneficial, but AWS is great for building blocks.
Are there any features or functionalities which would make the platforms more appealing to clients?
L: I don't think so. Any time when we needed to use one, we found what we needed for the particular customer. Whenever we used alternative platforms to AWS, like Google Compute Engine, it was mostly for cost or latency reasons. They were usually little reasons, so I wouldn't say that there were any missing features. Most of the time, it's a case of particular customer needs, which don't match the platform at a given time.
J: AWS offers PostgreSQL which, for some reason, is not HIPAA-compliant, as opposed to other platforms. Clients have had to engineer their own solutions in these cases, so it would have been nicer to simply spin-up a PostgreSQL instance and run with it. There are some very specific cases which aren't covered, but I wouldn't expect any cloud provider to go out of their way for these, given that it's not beneficial to the majority of the customer base.
Have you had interactions with any of their support teams or support resources?
L: We've used the cloud infrastructure support from Amazon Web Services, Linode, and DigitalOcean, which has fantastic documentation. When searching for technical documents, we either ended up in their directory, or the Arch Linux wiki pages. In terms of support for their own products, most of what we found was great. We had problems with Rackspace, but that was a long time ago. I think that they've improved since then.
We've had some recent issues with OVH, mostly because we dealt with a very new datacenter, based in Canada. It wasn't strictly a problem with the support, but rather the fact that, being so new, they weren't prepared to support all the features that we asked for. My experience has been mostly positive. There were some cases in the past where issues arose because a provider had a huge user base. There were broader issues which affected entire datacenters, not only us.
J: One of my gripes with AWS used to be that the support provided by them was minimal, unless the customer pays for it. This isn't entirely unreasonable, but AWS seems to be structured so that, as long as a person knows how to use them, they'll be fine doing their own thing. Once someone needs help, Amazon charges an arm and a leg for assistance that isn't even helpful sometimes. A client came to us a couple of years back, when AWS had huge issues with their Elastic Block Store, which even caused problems with people as large as Netflix. One of our client's databases was in the affected volumes, and they were trying to find paper support from AWS in order to get back-and-running. The support provided was limited to just acknowledging that the servers were down and that they should wait for the system to come back up. AWS may be better now, but that left a bad taste in my mouth. Most other providers that I've worked with offer base-level support to any customer. It's possible to email them or even make a call and receive a status update.
We have 5 additional questions. For each of these, we ask that you rate each platform on a scale of 1 to 5, with 5 being the best score.
How would you rate them for functionality and available features?
AWS - 5
Linode - 4 - J: It doesn't have many features, but what it provides is definitely great
Rackspace - 3
How would you rate each platform for ease of use and ease of implementation?
AWS - 3 - L: It definitely has a learning curve, mainly because of complexity, not because of bad design.
Linode - 5
Rackspace - 5
How would you rate them for support, as in the response of their team, and the helpfulness of available resources online?
AWS - 3 - L: The points deducted are mostly because of the paid subscription.
Linode - 5
Rackspace - 3
How likely are you to recommend each platform to a friend or colleague?
AWS - 4
Linode - 5
Rackspace - 3
How would you rate each platform for overall satisfaction with the platform?
AWS - 5
Linode - 5
Rackspace - 3
J: It all depends on what the client's needs are, so we are likely to recommend either of them.