Acting as your internal start-up, we address pain points and help you capture opportunities. Let us work together to take your business to the next level. Our experienced staff have developed systems to safely work within complex technology systems. Our small teams work independently to implement, test, and deploy solutions safely and quickly, maintaining the high productivity required to meet today’s business requirements.
There are a few items to consider when building software to be “cloud-native”. These considerations take into account key differences in how resources are allocated and availability with PaaS services and IaaS resources.
Key Considerations:
Scale Out over Scale up (Part 1)
Graceful Fault Handling (Part 1)
Multi-Zone and Multi-Region Deployment (Part 2)
Do Not Write to the Local File systems (Part 2)
Stateless Design (Part 2)
Serverless (Part 3)
PaaS Services (Part 3)
One of the traditional methods of scaling to meet increased load in on-premises environments is to Scale Up; simply add more CPU power, Memory capacity, or storage capacity to the server.
This is a common practice on-premises with both Single Server and Multi-Server hosting solutions. In the cloud, server resources are more of a readily available commodity. In the cloud, a new server VM can be provisioned when needed. For this reason, it is much easier to add more servers when extra capacity is needed.
An additional benefit of Scaling Out (adding more servers / VMs) is the increase in resiliency. If 1 server out of 10 goes down, it affects the overall performance of the application to a much lesser degree than if 1 server out of 2 goes down. Scaling Out and spreading load across server instances has many benefits, including higher availability, higher resilience against failure, as well as the ability to tweak server resources to optimize cost when comparing pricing tiers.
Every software system has failures.
When distributing load across multiple server instances, or integrating a distributed / microservices architecture, an application needs to be coded to gracefully handle all errors when possible. These errors can even include transient failures, such as not being able to connect to a database or service, isolated network outage on a single VM, or any other sort of error that occurs at random times for a short period of time and then goes away. When a call to an external service fails, the application can be coded with Retry Logic to re-initiate making the service call 1 or more times before throwing an exception.
Another possible implementation is to cache a user’s request using some type of message queue, so the user can continue with their work while the system handles the error and performs the requested work in the background.
One of the aspects to hosting applications in an on-premises environment that can easily become cost prohibitive is the ability to deploy to multiple datacenters for redundancy and resiliency.
Cloud providers like Microsoft Azure and Amazon Web Services are made up of many regions spread across continents and geographies that can be utilized for any cloud application deployment. There are also multiple Availability Zones within each region that can be utilized to enable application instances to be deployed to specific data centers within the Region. Application deployments that utilize Zones and Regions have the capacity to be globally resilient against Regional or Datacenter failures. This extra resiliency can be combined with Scaling Out to host applications with a much greater level of resiliency and availability than is possible in most on-premises data center environments.
When using PaaS services to host an application, it’s important to not write anything persistent to the local file system.
The reason for this is that multiple instances of the application running in the service do not share the same local file system as they are hosted on different VMs. Instead of writing to the local file system, any files and/or data that needs to be accessed across application instances should be written to a shared storage service like Blob Storage or other database services.
When designing applications to Scale Out, instead of Scale Up, the design to share state across instances can prove to be difficult depending on the overall application architecture.
Modern application architecture is to design applications to remain Stateless. This has become the modern standard in web application and Rest API design. It’s common to use Cookies with an HTTP-based application to remain Stateless, but another option is to use a cache service like Azure Redis Cache to share state across instances for applications that still require state.
Serverless computing, such as Azure Functions or AWS Fargate, takes the benefits of PaaS even further by adding an additional abstraction layer that enables an individual function of code to be deployed and hosted without requiring a full application to be maintained
This larger abstraction is integrated with input and output bindings that provide built-in capabilities to integrate with other PaaS offerings, as well as third-party services and applications. Using Serverless compute decreases the overall development and maintenance costs that enable faster time to delivery and easier production support.
Where a specific service is available for a task, using that service is usually a better choice than building a custom service using lower-level platform components.
These services have already been designed to deliver the availability, performance, security, and scale required by the most demanding customers—saving significant work and providing a service level that would be difficult and expensive to match. Using services built specifically for the cloud enhances the development team’s capacity to deliver value, in addition to providing an abstraction that removes many of the monotonous and time-consuming aspects of Server and Virtual Machine maintenance.