How to rock while standing on the ground - the cloud in a large organization and a small start-up

Kamil Mrzygłód
Calendar icon
17 kwietnia 2018

"What will moving to the cloud actually give me?" --- this question can be heard very often, whether in the context of a large organization facing the choice of a cloud provider, or in a small company to which we are proposing a new solution, so to speak, revolutionary and perhaps a bit scary from its perspective. Because how so --- from this point on we don't need machines, we don't need to maintain anything? What about costs, security and support if something stops working? The reality turns out to be, on the one hand, not as colorful as cloud providers portray it, but on the other hand, it's also not as scary as we see it ourselves.

Which companies will benefit most from the cloud?

I personally, however, was bothered by another rather elementary question --- does "size matter" when it comes to the cloud? When I encourage my client (a small start-up) to choose Azure, for example, am I cracking the whip on myself, or am I rather opening up new prospects? It turns out that, as usual, the truth lies somewhere in the middle.

The story is more or less as follows --- we have two companies, one is a large corporation related to medical devices, the other is a small business that manufactures its own IoT devices and makes money by providing its customers with reports based on data from those devices. There is no point in comparing scale here, as neither the financial outlay nor the regulations will be commensurate in the aforementioned cases. However, it turns out that in our daily work, the problems we face when designing cloud services are as similar as possible. But before I get into the similarities, I'd like to take a moment to show where the two topics nevertheless go in completely different directions.

Cloud in a small business

Without further ado, the first thing that comes to mind is cost. However, this is not about the monthly invoice (which, as you know, will probably vary by a few zeros) but rather how the company converts the money spent on the cloud into real profit. If we have, for example, 10000 devices and each device gives us 1 PLN, it is easy to calculate that the monthly revenue is equal to 10000 PLN. Now the question arises --- what percentage of revenue can we devote to maintaining a cloud solution, and why should we opt for one if the current one (traditional on-premises) is twice as cheap? If it is a one-person business, every penny counts. Such a customer is not easy to convince that the cloud is the solution for him --- because is it worth investing extra money if the profits are invisible?

The answer is simple --- of course it is! After all, by leaving behind the old-fashioned virtual machines and switching to the PaaS model, we gain something much more valuable --- time. We don't have to deal with operating, controlling and updating our machines and software. We don't have to administer them, manage access and secure them ourselves. If we spent 1h per week on this, on a monthly basis, it may turn out that the extra money invested in cloud will pay off after a few weeks --- the rest is pure profit. These are, of course, only rough calculations, they are nevertheless not completely detached from reality. To be honest, quite recently I put myself in the role of a vendor myself, when I decided to rewrite my client's outdated system, based entirely on PHP, MySQL, a dozen CRON jobs --- all on a single virtual machine --- to a modern application based entirely on PaaS components and serverless in Microsoft's cloud. The goal was simple --- to come up with a solution with identical functionality, while removing all the problem spots of the old software (saturating network connections, flawed architecture where one component blocked others, deteriorating performance) and the legacy infrastructure provider (unexpected server downtimes, poor support, zero scalability). It cost me quite a bit of time and was quite an interesting mental exercise, but in the end I ended up with a solution proposal that is estimated to be within the range of 200£ --- as much as the existing service. This is not much bearing in mind the following criteria:

  • we handle more than 100 million device events and can easily handle twice that number,
  • individual components are separated so that, for example, a problem in writing does not impinge on reading,
  • with a single slider in the cloud portal we scale out the selected service with zero downtime if we lack computing power,
  • we do not worry about updating infrastructure components and monitoring them --- this is the responsibility of our provider,
  • we can easily automate deployments, thanks to many built-in integrations, among other things.

Examples could be multiplied and multiplied. However, this exercise shows that the cloud neither has to be more expensive, nor does it have to complicate work, what's more --- it even makes it easier.

Benefits of the cloud in a large organization

The matter looks a little different in a large company. Here no one will argue about whether there is justification to pay PLN 500 or PLN 1500 for one or the other solution, if it delivers the business value that was expected. One can argue here that it is not justified to pay 3x for a similarly performing application, on the other hand in corporations there is not so much emphasis on cost optimization from the very beginning. This is the cost difference I mentioned --- we look at expenses completely differently if a solution consumes 10% of our revenue and differently when it is almost imperceptible (or at least invisible at first glance). Moreover, the cloud in large companies is not only development. Here there are often SaaS services (PowerBI, Office 365 and others), premium support, Active Directory integration and others, the value of which is often not so easily quantifiable.

The second thing that, in my opinion, makes the difference between a small and a large enterprise when it comes to the cloud is the way in which the optimization of the solution is approached. Let me cite another example of a client where we decided to completely abandon a traditional relational database and moved the whole thing to Azure Table Storage. For those who are not very familiar with Microsoft's cloud services --- Table Storage is a service for storing data (non-relational database), where it is placed in tables, which optimally can only query by two predefined columns (so-called Partition Key and Row Key). The reasons for abandoning the SQL database were several:

  • the need to remodel business domains for the new solution, in which many elements were not naturally connected,
  • reduction of costs associated with maintaining and operating the database,
  • better integration with other system components (we started using Azure Functions, among others),
  • emphasis on storage capacity rather than performance,
  • low variety of queries to the database.

There was one main problem with the above solution --- since Table Storage has no way to create relationships between tables, and any query without a Partition Key or Row Key is incredibly expensive, we spent a lot of time both modeling the individual tables correctly and querying them correctly. A lot of patterns were involved in writing and reading data in an optimal way. All this in order to keep the cost of the solution in line (and at the same time defend the concept). In the case of a large company, such a situation rarely occurs --- either we choose the simplest solution paying correspondingly more (in the described case, theoretically, we could simply switch to Azure SQL --- but it was both more expensive and less "fitting" solution looking at the nature of the data stored in the database), or we wait with optimizations until they are inevitable. Of course, I'm not talking here about serious oversights that automatically kill the solution in production. I'm talking more about situations where we avoid paying for something that could be avoided (such as reading an entire partition in Table Storage with a poorly constructed query --- the important thing is that in this service we pay to read EVERY record).

Typical advantages and disadvantages of cloud solutions --- independent of the scale of the organization

However, how does the issue of similarities I mentioned at the very beginning look? It is worth starting here with the rather high threshold for entering the cloud, which affects both a small startup and a large corporation. Giving up the traditional on-premises model where we control and manage everything and, as it were, giving credit to the cloud provider is often quite a challenge. Large companies may have an uphill battle here (more money often means additional support and dedicated specialists), nevertheless this is not a one-week endeavor. When I was introducing the cloud at my client, there were a lot of questions about what guarantees there were that the service would work. That guarantee is the SLA or Service Level Agreement defined for each component of the cloud --- it is unchangeable no matter what monthly invoice we boast.

One more thing to note here --- no matter how many people we employ, the public cloud does not guarantee us any compensation (other than that implied by the SLA) if we lose money during downtime of a critical service. In other words --- we can only recover the money invested in a particular part of the cloud infrastructure --- the profits resulting from our business are cut off, so to speak. Regardless of the size of our project, we must always reckon with the fact that there may be a fortuitous situation that will "ground" it. It is very important to properly design such a system taking into account all sensitive elements. For example --- going back for a moment to the described early company with IoT devices, during the design of the solution we asked ourselves questions to what extent the data collected from the devices (on the basis of which reports to customers are built) determines the fate of the entire enterprise. We concluded that the LRS (Locally Redundant Storage --- 3 replicas of data within one datacenter) model of the chosen storage would be insufficient from the point of view of company security and customer convenience, so we chose the RA-GRS model (3 copies locally + 3 copies in a completely different region with Read Only access). One may ask here what if we lose data in the second region as well --- I think, however, it is always worth using common sense and not complicating the solution if there is no solid basis for it. Also, this should not be confused with backup, which should be an integral part of our system, but by itself does not guarantee high application availability.

The last common element I'd like to mention in this post is a very positive aspect of the cloud, which may be due to my developer backgroun, but personally puts it above the old IaaS-based solutions --- the focus on actual development rather than fighting and configuring the infrastructure. I now recall with fondness the early days of my career, when every time we started a project, we had to organize machines, install the right software, take care of the right settings. There was also the element of providing security like controlling open ports, providing a VPN connection for the client. All of this wasn't just limited to local work --- the same had to be done on production machines and then maintained. In hindsight, a lot of time was spent on activities that the cloud solves immediately. Nowadays, working on both these big and small projects, I feel that I focus on proving a quality solution and building my own skills, while avoiding repetitive and avoidable activities that effectively take the fun out of the work. It is encouraging how, for example, my current team has time to make several prototypes of the architecture of the system under construction while looking for the optimal solution. All this is due to the fact that we don't waste time figuring out how to run and connect the various components, PaaS does it for us.

We could probably talk about the cloud in organizations of all sizes for a long time, but I hope I managed to present those basic elements that I paid the most attention to. So when it comes to the cloud, does "size matter"? At the end of the day, it seems to me that no. There may be differences at the level of competence (it's easier for a large company to hire a lot of great specialists), technical support (larger organizations boast various additional contracts with the vendor that can provide additional benefits) or capabilities, but at the end of the day, both in a start-up and in a corporation, the most valuable thing is the same. The cloud accelerates development, takes on some of the responsibility (such as maintaining and configuring infrastructure), allows you to reduce unnecessary costs and invest the money saved elsewhere. Moreover, the whole current cloud revolution is something that will not stop in a year. By delaying (or avoiding) the transition to the cloud, as it were, we make our competitiveness lower. All of these values are equally important in smaller and larger players, so don't be afraid to rock the boat if you stand firmly on the ground at the same time.

Read also

Calendar icon

28 marzec

RABATKA Action - Discover the spring promotion!

The annual spring promotion is underway: RABATKA Action, thanks to which you can save on open training from our proprietary offer.

Calendar icon

8 marzec

Don’t miss the opportunity - register for the IREB exploRE 2024 conference and meet the best experts in the field of requirements

We invite you to the IREB exploRE 2024 conference dedicated to requirements engineering and business analysis. The conference will ta...

Calendar icon

18 styczeń

How to prepare for the ISTQB® Foundation Level exam?

How toprepare for the ISTQB® Foundation Level exam? Check valuable tips before taking the test.