The Cloud Is The Cloud, Right?


Understanding The Value of Native Cloud Systems

Who today has not heard the phrase “We’re on the cloud.” Or “We’re cloud based.” Perhaps even your own organization is talking about moving to “the cloud”.  We all know by now what that generally means.  But do you really understand the difference between operating in the cloud and being “born” in the cloud?  For most of us out there, do we really even care or need to understand what this means?  The reality is most of us probably don’t.  

However, if you are someone who makes decisions regarding your organizations technological infrastructure, SaaS (Software as a Service) or PaaS (Platform as a Service) then the differentiation between the types of cloud uses should be an important part in your decision making process.  We’re going to take a 50,000 foot view of the difference between “Operating” or being “Hosted” in the cloud versus being a “Native Cloud System”.  We’ll skip the definition of the cloud because it’s almost 2020 and if you don’t know…well, you don’t know.

I’m sure across industries companies are presenting their systems toting the term “cloud based” or expressing to their prospects how they are modern and current because their system is now “in the cloud”.  So what the hell does that really mean?  Here is a Cloud 102:

Being “In The Cloud”

This is the terminology generally used by organizations who have operating systems which are fully or partially (remember that) hosted in a cloud environment.  This is awesome right, they must be up with the latest tech if they are in the cloud, right?  Not necessarily.  First, kudos to those organizations who recognized the significant cost and operational savings by transitioning some or all of their operating systems to a cloud based environment (regardless of what it is – we’re going to try and stay away from pointing to any one in particular).  For anyone who has been involved or had insight into the costs associated with hosting and maintaining physical servers on-site, you know the significant savings this can bring to an organization.  Which is why so many have been making the switch.  A small operation can spend between $15K-$55K per month to maintain and run full time servers to fulfill their company’s needs and that does not include the employees who maintain it as well.  We’re not going to talk about the how’s of the decision to migrate from on-site servers to the cloud, but rather just touch on the variations of actually being there.

Fully Migrated – A company that takes their currently managed databases and transfers them to run them in a cloud environment (this is a 102 lesson so we’ll save the description of the tools to do so which vary from one provider to the next until the 104 course.  We’re just going to keep it in very general terms so everyone can understand).  These databases now basically post migration, do the same thing they did before – just from a different location.  So whereas the benefits to the company are significant, to the end user they can be minimal since the database / system is still essentially what it was before it was in the cloud.  So if it was a great system before, then it will continue to be.  If it was garbage, then being in the cloud is not going to change that.

Partial Migration – The company moves some of their functions, perhaps their core operating systems or maybe they are afraid to let go and they only transition their non-essential databases to the cloud or there are instances where for certain reasons, they must keep a portion of their infrastructure on-site.  Either way, they are not 100% migrated, now some companies depending on what they do will still happily tell their customers they are in the cloud, without divulging to what extent and what functionalities are operating there.  Again as with before, this is not a bad thing, it is a matter of what is there and how did it run before?  Many times though, a company will present itself as being in the cloud even when they are only part way there.

In both the above instances, the company has simply moved their current database / system from on-site management to a cloud based solution.  To the end users, with the exception of perhaps some improved latency (communication speed) this is not going to make a difference if your system was already poor prior to the migration.  Hosting it in a cloud environment is not a magic fix and it doesn’t make the organization any more proficient or modern as the technology they are running is still what it was prior to.  For example, if I’m running a database from 2002 that has not been modified or updated (yes they exist), then being in the cloud just means that I have an old database that I don’t have to pay to store on-site anymore.  So if you are an end user of that platform, being in the cloud isn’t changing your life at all.

Partial Conversion or Adaptation – not the “official” terminology but I think my description helps understand the action better.  Now we start to talk about the actual functions being upgraded.  Cloud services offer many beneficial features, but these features like anything else need to be configured and/or programed.  You can’t just plug in your system and they work.  Companies can now take portions of their systems functions and have them run and be managed utilizing a cloud based process.  Depending on the functions being converted, it may have benefits such as quicker processing, ability to manage more requests, etc.  Again I am oversimplifying, the bottom line is they take pieces of their current database / system and have those tasks performed with a newly implemented cloud function.  This may allow the organization to provide a new feature to their client that ties in with their existing system or improve some current functions of their database that benefit their end users.  Obviously, the same rule as above on quality still applies – but in these instances they are actually using the technology and tools to begin improving some of their systems functionality.   

In each of the above scenarios the databases are what is referred to as a “Transplant”.  It is at it’s core the same database which has been transplanted to a different environment.  Obviously, there are benefits to this, it may enable them to take advantage of certain features and capabilities that cloud service companies like Amazon, Google and Microsoft offer.  They can often improve performance and introduce new functions if they invest in the development for those tools to work with their systems.  This makes it sound simple, but the reality is migration and conversions can be very complex.  There is coding involved, transferring of large amounts of data, configurations and more.  Ultimately, when they do transplant barring significant new development and/or coding, they are still operating on the same / similar core platform and although they may now have features and functionalities that were not available to them previously, they are inherently limited in their ability to take full advantage of the cloud.  

Native Cloud Systems 

Enter the Native Cloud System.  This is a system that was not transplanted from an previous environment but one who from the first line of code to last was created to operate within and with a cloud environment.  These databases / systems are for all intents and purposes “born” in the cloud.  As such, they have the ability to fully leverage all of the functionality and reap the benefits of all the related cloud services.  Native Cloud Systems are not faced with the technology debt or obstacles that are inherent with databases created even five years ago.  

There are many benefits for Native Cloud Systems, such as adaptability, increased processing speed,  immediate scalability, and reduced operating costs are just a few.  Unlike, their transplanted ancestors that operate in accordance with the data base structure they were created with; Native Cloud Systems do not face the same operational shortcomings because they were designed to perform, store data and execute functions exactly the way the cloud services design intended them to.

I was thinking about a different analogies to explain this and the easiest I could think of to encompass it all, was building your own powerful computer at home.  You designed and built this amazing powerful tool.  You invested a lot of money to get all the right parts and it does everything you need it to do.  Your family uses it to do everything they need as well.  You have to keep it running because everyone is continuously using it.  It generates a lot of heat so you have to keep it cool too, but you can’t freeze out the whole house so you put it in a special room.  You have to continually check it to make sure it’s operating correctly and all the parts are working, the fan is not burning out and all the routine maintenance things you do for it.  You have to pay for the electricity to keep it running because you can’t really shut it off.  Your friends have gotten wind of it too so now they are connecting to it but you can only handle so much and eventually you have to tell people no.  In a few years, it’s no longer new, your investment has depreciated and new and better tools are coming available, but you still have to keep it running.  You could update it but that’s going to be expensive and the new tools don’t really work with your design.  You realized you could save some money by having someone else hold this for you and take care of it because they do this on a larger scale.  So you give it to them to do.  You cut down your electric bill, get your room back, but you are still limited to what you can do because you didn’t really upgrade it, you just moved it.  This is a transplanted system. 

Now your kids took a coding course and decided to design a system that does everything your computer does.  You laugh because you know they don’t have the money to put into building anything near the powerhouse you did 5 years ago.  But you see them coding away.  You discover they learned that they could own a design and code it around existing proven technologies, essentially using the raw tools built by someone else to make their vision come to life.  Someone else made the monetary investment and lends it to him for a fraction of what you paid to build your now antiquated box from scratch.  Someone else handles the maintenance, and is continually developing new tools allowing your kids to improve on their design and services.   You tell them that they can’t increase your electric bill, but unlike your system which has to stay running all the time, theirs turns on and off as needed and they only have to pay for what they use.  They are able to do everything you did, cheaper, faster and better while adding new features to make everyones life easier.  Their system can continually grow and evolve, they don’t have a huge electric bill, hardware bills or headaches of worrying about if the fan goes on their computer.  This allows them to focus on new ideas and ways to used the innovations being presented to them.  Now everyone except your best friend (who is seriously contemplating it) is using their system.  Their friends told their other friends and whereas your system had to stop when everyone on your block used it.  They have virtually everyone in your town active almost overnight with the ability to add the state and have the resources available for it to handle even more.  This is what it is like to have a Native Cloud System.  Your concept.  Your code.  Their tools and infinite possibilities.

Now you and your kids use the same company for your systems and you notice your bill is higher than theirs and just can’t figure it out?  But because your systems design requires it to run constantly, you are paying for it continuously.  While they have designed a system which performs tasks and then turns off when it’s done.  Yet another difference between transplanted and native systems.

Let me be clear, that this isn’t intended to be a negative article about transplanted systems.  My goal was not to diminish their capability. There are many transplanted systems in whole or part with major corporations that are efficient and effective.  The goal of this article is to help you understand that even those successful Transplanted Systems have some inherent limitations versus Native Cloud Systems.  Like that old computer, most of them, because of their design, need to run continuously.  The way they store data and the structure of their databases are from yesterday so they face a certain degree of technology debt which they can’t just overcome without re-writing their database entirely.  There are many companies that are doing just that and I would predict you will continue to see that trend pick up speed as we enter the next decade.

  The take-away from this article is hopefully a very basic understanding the fundamental differences and that when someone tells you their system is modern and capable because “We’re in the cloud” you now know to ask a few more questions.  Are they 100% cloud based?  Is their system a Native Cloud System or a Transplant?  If the latter, do they plan on converting and if not, why?  Let them explain what the benefits of them being in the cloud are for you.

Our A.S.G.A.R.D. system was born in the cloud.  Although we are not the first 100% cloud based system, we are proud to be one of the first in our area of the market to present a Native Cloud System offering to our clients.  ASG is a proud AWS based organization and every developer and architect that touches our platform is AWS Certified.  When we present our offering we are happy to discuss the benefits both upfront and behind the scenes to our clients.  Anyone presenting as a cloud based system to you, should be prepared to do so as well.

Uncategorized

Leave a Reply

Call Now Button
Show Buttons
Hide Buttons