Clutch.co, a B2B research and consumer review service, recently spoke with Will Farrell, Lead Software Architect at MojoTech, about cloud infrastructure options and various cloud solution options. Will's interview gives an insightful look into how MojoTech evaluates cloud solutions for our client projects.
Introduce your business and what you do there.
Will Farrell: MojoTech is a digital creative agency focusing primarily on software engineering and design. We also have product managers that help potential clients refine their vision, building a concrete plan on which we can then execute progressively. Certain project scopes demand other expertise. For instance, we also provide DevOps and related operational services, like continuous integration and ongoing infrastructure management.
I’m the lead architect of MojoTech. I focus primarily on software architecture and design. I’m involved early on all new projects in order to set a realistic path going forward. I take an initial set of feature requirements, and then select an appropriate technology for development, choose the hosting providers and other similar details. As the project moves on, I remain in periodic contact, especially for more complex features that require advanced software design. More broadly, I monitor all of our projects and try to identify areas where we can streamline internal processes, communications, documentation, etc.
Does MojoTech initially suggest specific cloud solutions for new projects?
WF: We definitely try to match up technology with the client and project and don't have an agenda in terms of pushing a particular provider. All things being equal, we recommend the solutions we're more familiar with.
Based on our past experience and clientele, we've found that Amazon Web Services [AWS] tends to be an appropriate fit in numerous cases, especially for those clients graduating from proof-of-concept to viable products with actual users, which will require flexible support and ongoing maintenance. One of the things about AWS that we try to leverage is the variety of services they provide within the product suite. We can take advantage of their hosted databases, hosted load balancers, and so on. This lets us move faster and more efficiently, usually saving money for the client. For example, it’s a very appealing solution for legacy organizations with obsolete internal processes and an entirely on-premise IT environment.
DigitalOcean is a solution we'd potentially use for a smaller-scale project. The service itself has fewer offerings, especially compared to AWS. The service is used when we need to spin up a box quickly, running a one-off service. We’ve proposed this solution only a handful of times. It still has attractive features like distributed deployment capability, remote infrastructure management, and a decent support network.
Docker is more of a niche platform. We use it in development environments more frequently than we do in production environments. When we do use it in production, we usually have a very good reason to do so. A key example of this was with a hosted platform for running user-generated code. The existing client platform ran on AWS, but we also had a requirement of running that code in isolation. Docker provided a nice fit there, but we wouldn't necessarily apply it to one of our more run-of-the-mill web applications, given the trade-offs. We're not willing to pay the additional complexity cost when something simpler like running on AWS with Elastic Beanstalk is sufficient.
What are some business challenges which you are trying to address by using cloud technology?
WF: Modernization projects seem to be very prevalent. A lot of companies running internal legacy systems eventually encounter some kind of scaling related issue. It becomes very difficult to manage those environments, especially if you have unpredictable growth. They aren’t usually architected with sufficient flexibility. As a result, those systems can eventually fail under the weight of their own success. Cloud solutions like AWS are frequently the right choice for these companies unless they have extremely stringent security requirements.
Another situation we encounter is product scalability. It makes sense for most fledgling, app-based businesses to make use of cloud solutions from the very beginning. The reality is that they’ll be able to manage their resources and costs far effectively is they use cloud solutions. The flexibility they can offer, not to mention the variety of available features, means the company can scale the delivery infrastructure in parallel with the app itself.
Were there any high-profile projects you've encountered, where the project requirements led to completely rearchitecting something from scratch? What was the outcome?
We don't tend to propose huge, monolithic rewrites if we can avoid it, especially within large systems. It's extremely risky and it's difficult for us to estimate how long it will take because we’re unfamiliar with the system. I can't think of a time when we may have recommended an approach like this because it was the least risky decision.
We usually try to carve off a chunk of the problem. If the existing legacy monolithic application can't run in the cloud, we may carve off a specific piece of functionality, and then reimplement that in such a way as to run it externally in the cloud. If we're happy with that process, we might carve off yet another piece of functionality over an extended period of time and repeat the process. It depends a lot on the risk tolerance of the individual client, as well as the complexity of the application involved. We then might also have to include longer integration, configuration and testing periods. That alone could undermine the project for certain clients, which is why the risk tolerance is such a determining factor.
What recommendations would you make to companies that are only now considering cloud solutions?
WF: Anytime someone is looking to move from one environment to another or to change their software, the first few measures I would take would be ensuring that the relevant processes are both well-documented and well-tested. Having sufficient tests has proved to be extremely helpful when doing any sort of migration or transition. Without having a clear baseline of the software's performance in different environments and situations, we are forced to perform manual quality assurance testing for each and every new feature we develop and implement.
When we pick the hosting environment for a client migration, we’re always conscious of any architectural or design paradigms that the environment itself might demand. For instance, if we want to move into the cloud from using a legacy database with no hosted version, we need to keep in mind that we will need to manage a cloud version of it, which might be more work than we're expecting. Small changes can pay dividends in this case, for example, moving to an actual AWS-hosted database. If we're using a version of SQL server that is not compatible with AWS, we might want to move to another SQL version in-house, before moving everything to the cloud. This way, we will minimize the number of changes and moving pieces. We try to make those decisions ahead of time whenever possible.
What are the costs of using these different technologies, comparatively-speaking?
WF: Our progression, as we go from smaller to large projects, is to begin locally, deploy to a service like Heroku as soon as possible, and then move to something like AWS. We tend to do it that way because we're balancing the actual monetary cost of hosting with the time cost of the developers who will be potentially maintaining the systems. I would say that's something important to keep in mind. Oftentimes, we will be making a trade-off between time and money.
Running on AWS will potentially cost less money than Heroku. By comparison, even though DigitalOcean or running your own servers might cost less on paper initially than the first two, the ongoing maintenance cost of running the environment will outstrip the cost of deploying it.
How that relates to potential enterprises moving to the cloud for the first time might make cost estimations more difficult. It's tough to say how much something will cost without a specific example, but it definitely dramatically offsets the calculations, especially around maintenance. AWS will handle much of that, and it's also important to choose a provider that can offer paid support, thus reducing the need for a fulltime operational staff.
Depending on the workload of the software, if we move to an architecture like AWS Lambda, we can save a significant amount of money, given that we don't need to be running the hardware all the time, and we only pay for what we use. There are multiple tools that are designed to minimize the AWS bill. This is an option that wouldn't exist with an on-premises infrastructure. Even if the machine is turned off, it's still owned by the company so it would remain idle.
Scope creep can occur in almost any technology implementation. What are some aspects of an implementation that a client might be able to forego to help prevent it?
It's difficult to suggest broad categories of things that we would outright drop. More often than not, we try to reduce the scope in the context of individual features. For example, we might try to reduce scope by choosing a particular implementation that will be less costly going forward, often at the possible future cost of making it more difficult to enhance or change the feature. So we could make the argument that it would be less expensive to deliver a feature without sufficient test coverage. If we choose not to write tests, it will theoretically be delivered faster and for less money. Then, as soon as we try to modify that feature, we might be spending a lot more, given that we don't know if we're causing a regression.
We also try to keep in mind the balance between technical debt and the speed with which we're developing at any given point in time. The fact that we work so closely with our designers throughout the process means we have fewer isolated interactions. That translates to quicker delivery speed. Our product managers help prioritize features to balance product viability with cost. All of these things combined keep us within the budget requirements.
Client goals should always be taken into consideration. If they're seeking a relatively low-fidelity prototype meant to obtain funding, we might not care too much about testing in the present; we simply want to get a demo out as quickly as possible. We would otherwise be trading some opportunity costs for technical improvements that don't actually provide value to the client, given their goals. Defining those goals at the outset should inform your cost management approach.
Is there a specific reason behind utilizing a particular platform over another?
WF: One example when we've used DigitalOcean was when we were delivering a completely new front-end also developed by us. Because of some security requirements, the team building the front-end didn't have access to the backend, so we needed to spec and build a fake API server, which was hosted on DigitalOcean. There weren't many constraints in terms of uptime; we knew that the cost of maintenance would be low, and it was the fastest and simplest way of getting the system up and running at the time.
On similar types of projects, where we might not need to be as concerned with high availability, and where we only want quick-and-dirty hosting for prototypes, we will choose DigitalOcean.
AWS is ideal for production-ready environments, where elements like high availability of multiple servers in disperse regions, as well as database replication, are important. The client could be less willing to stomach the idea of whatever solution we're building, so high availability is a good trade-off.
Another reason for choosing AWS is the hosted Elastic Search. Most projects that we tackle have PostgreSQL, MySQL, and other databases, for which AWS offers many integration options. It's one less thing that our developers need to do, and it's something that the clients don't have to worry about as much, going forward.
We use Heroku a lot for smaller, standard web applications. We use it when we’re saving development time at an additional cost for hosting.
We like to use Docker when it comes to local development, saving developer’s time as new resources go off and on projects. We can curate, maintain, and share development environments in a way that minimizes the time that any new developer will spend getting things installed and up to speed with code production.
We use Docker when we have specific requirements for running code in isolation if there's something exotic about the environment. It's more of a judgment call during the project, not a go-to solution. In most cases, there's no need for us to pull that kind of complexity.
Are there any special or unique offerings within each platform?
WF: Usually, when using AWS for a client, we will create a new account just for them. It makes for a relatively seamless hand-off: we can give them the keys, setup billing, and it will be all theirs.
Many of the clients that come to us don't have a staff of developers or any way of operating and maintaining the environments we create for them, so they also get a lot out of the hosted databases and file systems offered by AWS. The less they have to do, the better.
Docker is a niche platform. Many of the use cases we've had for it have been so dramatically different from one another that it's hard to pick out any real patterns. Being able to build a Docker image and handing it off to a client who will need to deploy something behind a firewall, makes the process easier than having to install all necessary prerequisites for a particular piece of software on their internal machines. If there are constraints like not having access to the machines on which the software will be running, it will be difficult for us to setup the environment. Docker is a nice tool to use in those circumstances.
Have you had interactions with any of their support team or support resources?
WF: I have interacted with AWS support, and the team has been generally responsive. For instance, we have discussed a data migration from an on-premises solution to a cloud database. The support team solved some of the problems we encountered along the way. I haven't had any bad experiences with them.
Given the way in which we're using DigitalOcean, and possibly due to its relatively low complexity, we haven't had a need to contact support yet. The out-of-the-box solution is designed to require minimal intervention. Once you setup the environment, it essentially runs itself.
I've definitely run into more problems with Docker, but I've also used it for a long time, 2–3 years, since version 0.5. It was a beta software at the time, so I wouldn't blame the company. We haven't talked to their support directly, but the pace of Docker's development has been frustrating at times. We've tried to build stable solutions on top of something unstable, but the specific circumstances made it that the pros of using Docker outweighed the cons, even though they were considered. They could definitely improve their offering.
What are the biggest challenges that you’ve encountered when deploying cloud solutions?
WF: Depending on the nature of the legacy software, one of the biggest challenges we've run into is security. We have been working with big enterprise clients, like a Fortune 500 financial institution that came to us with very stringent security requirements. Building a custom cloud environment that replicated their existing internal one, while meeting the same security specifications, proved to be very challenging. Situations like those almost always require some kind of hybrid solution, but things can get even more complicated if, for example, the system we’re trying to build is meant to manipulate unknown confidential data. Those project constraints coupled with aggressive timelines put a lot of pressure on developers.
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 DigitalOcean - 3.5 Docker - 4 - The platform has set the standard in many ways. If we're considering containerizing applications, it would make sense to have Docker at the top of the list, but it's lacking in terms of the features that an enterprise would want, especially around security.
How would you rate the platforms for ease of use and ease of implementation?
AWS - 4 DigitalOcean - 4.5 Docker - 4.5
How would you rate them for support, as in the response of their teams, and the helpfulness of available resources online?
AWS - 4 DigitalOcean - 4 Docker - 4
How likely are you to recommend each platform to a friend or colleague?
AWS - 5 DigitalOcean - 4.5 - I'm more likely to recommend it to a friend than to a colleague. Docker - 3.5
How would you rate them for overall satisfaction with the platforms?
AWS - 4.5 DigitalOcean - 4 Docker - 4
