Going Cloud Native

  • Comments posted to this topic are about the item Going Cloud Native

  • Our systems are predominantly cloud native.  For data warehousing handing someone else the headache of exponential data growth is extremely attractive.

    Our infrastructure manager said that one of the attraction of the cloud is that you can scale down.  You no longer have to try and guess workload increase over the lifetime of a server you buy for your data centre. You rent for the demand that you have today and if demand materialises, then you choose the next instance size up. That is, if your chosen tech even has an instance size.

    Google BigQuery charges you on the basis of the data volume you query.  Physical storage and compute power are managed for you.

    AWS Lambda functions and Google Cloud functions spin up and execute when they are called.  They can save a lot of money if the calls to them naturally ebb and flow or are functions called infrequently.

    The range of data science tools available in the cloud is greater than a company would have if buying for on premises installation.  That is the hidden cost of an RFI/RFP process largely dispensed with.

    DBaaS is attractive to many because their DB workloads are the sort where the on premises equivalent would be one the DBA would watch but probably rarely need to touch.

    That said, old school DBA skills do come in handy diagnosing performance issues though the nature of a managed service is that many of the tweaks to configuration are not available to you. You have to design around the problem.  Getting the data model right becomes the most powerful weapon in your arsenal.

  • Is there a different in how you architect an app, depending upon if you choose a IaaS vs. PaaS approach? If we just did a lift-and-shift the VM's into the cloud, does it mean we don't have to re-architect the app?

    Rod

  • Doctor Who 2 wrote:

    Is there a different in how you architect an app, depending upon if you choose a IaaS vs. PaaS approach? If we just did a lift-and-shift the VM's into the cloud, does it mean we don't have to re-architect the app?

    A VM hosted in Azure (Iaas) is conceptually no different than a VM in your corporate data center. For example, Azure has a service that can snapshot images of on-prem VMs to Azure Storage, and in a disaster recovery scenario, the images can be mounted as Azure VMs. Ideally, your entire stack (databases and applications) would be hosted in Azure - but a hybrid solution can work well too.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • When it comes to Azure billing, there are techniques you can use to save big time. For production resources, you can leverage resource pools or auto scale DTU up and down for specific instances on a schedule. For development and QA VMs, you can provision then as "spot instances" so they leverage unused resources at a discount, and you can setup a schedule to stop the VM each day after hours. When the VM is not running, you're only paying for storage cost, which even for several hundred GB would be less than a dollar a day. It can sit like that indefinitely, and when a developer needs to use the evicted spot VM, they simple go into the Azure dashboard or use a PowerShell script to re-start it.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Doctor Who 2 wrote:

    Is there a different in how you architect an app, depending upon if you choose a IaaS vs. PaaS approach? If we just did a lift-and-shift the VM's into the cloud, does it mean we don't have to re-architect the app?

    The PaaS services often have slightly different feature sets. They also need better retry logic and error handling as the cloud inherently can move connections around.

     

  • Doctor Who 2 wrote:

    Is there a different in how you architect an app, depending upon if you choose a IaaS vs. PaaS approach? If we just did a lift-and-shift the VM's into the cloud, does it mean we don't have to re-architect the app?

    The PaaS services often have slightly different feature sets. They also need better retry logic and error handling as the cloud inherently can move connections around.

     

  • Eric M Russell wrote:

    Doctor Who 2 wrote:

    Is there a different in how you architect an app, depending upon if you choose a IaaS vs. PaaS approach? If we just did a lift-and-shift the VM's into the cloud, does it mean we don't have to re-architect the app?

    A VM hosted in Azure (Iaas) is conceptually no different than a VM in your corporate data center. For example, Azure has a service that can snapshot images of on-prem VMs to Azure Storage, and in a disaster recovery scenario, the images can be mounted as Azure VMs. Ideally, your entire stack (databases and applications) would be hosted in Azure - but a hybrid solution can work well too.

    Thank you, Eric. In 2020 it appeared like we were moving quickly to go to the cloud. Now it seems like the wind has gone out of the sails for going to the cloud.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • I would encourage everyone to do research into how much it will cost to host stuff in the cloud.

    We have a simple web application with a small database in the background, and after we moved it to AWS we found it was costing us about $500 per month, I think because the application is in .Net.

     

  • Steve Jones - SSC Editor wrote:

    Doctor Who 2 wrote:

    Is there a different in how you architect an app, depending upon if you choose a IaaS vs. PaaS approach? If we just did a lift-and-shift the VM's into the cloud, does it mean we don't have to re-architect the app?

    The PaaS services often have slightly different feature sets. They also need better retry logic and error handling as the cloud inherently can move connections around.

    I prefer using a PaaS approach, to IaaS. But it looks to me like adopting a IaaS, lift-and-shift approach is the path of least resistance.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • timwell wrote:

    I would encourage everyone to do research into how much it will cost to host stuff in the cloud.

    We have a simple web application with a small database in the background, and after we moved it to AWS we found it was costing us about $500 per month, I think because the application is in .Net.

    Hello Tim,

    I'm very interested in learning more about your experience. Mainly because I am a .NET developer. What sort of a .NET application was it?

    Kindest Regards, Rod Connect with me on LinkedIn.

  • timwell wrote:

    I would encourage everyone to do research into how much it will cost to host stuff in the cloud.

    We have a simple web application with a small database in the background, and after we moved it to AWS we found it was costing us about $500 per month, I think because the application is in .Net.

    The cloud isn't always cheaper, but often can be. However, if you are trying for the low end for a single thing, the initial cost is high. If you are moving bigger things, then the costs start to make more sense.

  • Rod at work wrote:

    timwell wrote:

    I would encourage everyone to do research into how much it will cost to host stuff in the cloud.

    We have a simple web application with a small database in the background, and after we moved it to AWS we found it was costing us about $500 per month, I think because the application is in .Net.

    Hello Tim,

    I'm very interested in learning more about your experience. Mainly because I am a .NET developer. What sort of a .NET application was it?

    It was an ASP.NET application we developed in-house that referenced a SQL Server database to record dates of employee training.

    Sorry I was not involved in setting up or paying for the AWS part of it so I am not sure what we were being charged for.

  • Over the 2016-2019 time period my company shut down five corporate datacenters and moved almost all of it to Azure or AWS via lift and shift IaaS methods.   For scale, we are a Fortune 500 company with production facilities in mostly rural locations throughout the US and Canada.  Our experience has been that the initial migration didn't really save money and in many cases cost more (sometimes much more).  What it did was provide a way to see much more clearly where the costs were coming from.  Once you can see them it is possible to have a rational discussion on how to reduce those costs.

     

  • Rod at work wrote:

    Eric M Russell wrote:

    Doctor Who 2 wrote:

    Is there a different in how you architect an app, depending upon if you choose a IaaS vs. PaaS approach? If we just did a lift-and-shift the VM's into the cloud, does it mean we don't have to re-architect the app?

    A VM hosted in Azure (Iaas) is conceptually no different than a VM in your corporate data center. For example, Azure has a service that can snapshot images of on-prem VMs to Azure Storage, and in a disaster recovery scenario, the images can be mounted as Azure VMs. Ideally, your entire stack (databases and applications) would be hosted in Azure - but a hybrid solution can work well too.

    Thank you, Eric. In 2020 it appeared like we were moving quickly to go to the cloud. Now it seems like the wind has gone out of the sails for going to the cloud.

    A good start is deploying any new development databases to IaaS VM or Azure SQL. Once everyone dips their toe in the warm water and can see there really are no sharks, they'll eventually wade deeper.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Viewing 15 posts - 1 through 15 (of 19 total)

You must be logged in to reply to this topic. Login to reply