Buy your own cloud, off the shelf

The hybrid cloud as we have known it is a marriage of two very different architectures forced to work together. It was a workaround for people who wanted to move to the cloud but were unsure. Or had way too much invested on-premise but were willing to take some systems to the cloud. The tools were forcefully modified to work with both. The on-premise tools were providing plugins for the Cloud and vice-versa creating a mesh of toolsets making it difficult for DC admins to work with the so called “Hybrid” cloud. It was nothing more than a work-around to prevent people from losing their On-Premise investments and still be able to use the cloud for something, if not everything.

But Hybrid is passe. The future is called (or at least should be called) the Seamless Cloud. The same architecture, same tools, same features and services for the Private AND the Public cloud.

Introducing, Azure Stack. A cloud appliance that makes the Public Cloud Private.

If there is one technology that has the power to make a wave like what Windows did for Personal Computing, it’s Azure Stack. Think about it… being able to Install the Cloud anywhere you want, expanding into the public cloud without having to think about changing your design or architecture.

Azure stack opens up many possibilities and makes developers life much easier. Most importantly it brings PaaS to On-premise, and that in my mind is a huge efficiency for developers. All those Open Source tools that you would otherwise take up your time to setup are now available as out-of-the-box services on a tried and tested cloud scale architecture. Though currently only a limited set is available, but what’s possible in the future looks exciting.

What’s also really cool is that all of Azure Market Place services are available on Azure Stack. So all those great services built by our partners and independent software vendors that are available on Azure Market Place will run on Azure Stack.

In my personal opinion, Azure Stack should not be even called as Hybrid. Hybrid by definition is a combination of two very different (often opposing) entities. While Azure Stack is the public cloud in your data center.

A one line definition of Azure Stack: Azure Stack is the Azure IaaS and part of Azure PaaS installed in your Datacenter.

It is available as an Appliance from Dell, HPE, Lenovo, and Huawei.

Avanade is about to join the list.

This Whitepaper on Azure Stack is a good place to start understanding the concepts.

In this article, I wanted to cover some real industry scenarios ideal for Azure Stack.

Global corporates, local laws

This is my mind is one of the most compelling applications of Azure Stack. Global companies are building systems for their internal and external consumption but are challenged by local country laws when it comes to putting data on the cloud. Currently, they have only two options,

  1. Build their systems using traditional frameworks and host it as an IaaS on the public cloud where it’s allowed and move it on-premise in locations where laws are not cloud-friendly. Advantage is that they don’t have maintain two separate versions (mostly). But they lose out on all the advantages of the PaaS cloud brings to the table.
  2. Build a cloud version using a combination of PaaS and IaaS as appropriate for the public cloud and build a separate on-premise version for countries where laws are not cloud-friendly. Advantage, at least the cloud version is using best-of-breed services and all the cloud advantages. Disadvantage, multiple versions being maintained for cloud and on-prem deployments.

This is an ideal scenario for Azure Stack. Keep the same architecture on Premise and in the cloud and reap all the benefits of the cloud. But deploy on-premise or in the cloud at will.

Value Added Services for heavy industry automation

Manufacturing automation companies have embedded control systems that provide monitoring and diagnostics for these high-cost and critical equipment. Lot of times they want to collect all this information from entire shop floor and analyze data, provide balcony-view dashboards etc. Latency is important and none of the data really needs to go to the cloud. Currently the only choice for them is to build these applications using a host of different platforms and frameworks and then install all this on a local server in the factory connected to the shop-floor Sensor Gateways. And then maintain upgrades and patches for these servers. Selling just the software means different setup environments and a maintenance and upgrade nightmare.

Azure Stack is once again an ideal solution here. All the required IoT and Analytics frameworks bundled as services on a box. And the deployment could be cloud based using AKS (Azure Container Services). The automation vendor can bundle an Azure Stack appliance as a part of their automation system setup. All the heavy IoT ingestion, analytics etc. can be on this appliance. The industry term for this is “Purpose-built Integrated Systems”.

Online-Offline systems

Online/Offline applications have been around for a while to support applications that work in an environment where connectivity is not always guaranteed. But these scenarios were limited to a Client-Server setup. In situations where connectivity is not particularly good, but you need the application to keep working and collecting data. Simple data sync platforms would then sync the Data from the Client to the Server.

But applications have now evolved. Client systems now have to do critical analytics and a lot of heavy lifting. In such situations too Azure Stack would be an ideal fit. A system that can be completely functional in a disconnected mode and sync up when the connection is available.

These are just a few scenarios for Azure Stack that we see in the industry. But it’s only limited by your imagination.

Caching in on Scale and Performance – Part III

In this concluding part of the article, I would like to discuss the various Cache management methodologies. But before we delve in that, Architects and Software Designers of today need to first make sure they are using the right Database/Storage technology. Because a Distributed Scalable No-SQL service like CosmosDB with it’s concept of request units (RUs) might not even need caching. The scale issue is solved by partitioning, distributing and scaling the database itself.

But if your design calls for a classic RDBMS style database, then a Caching layer and caching techniques need to be thought through.

In this section we will cover Cache Updates techniques and Caching Infrastructure considerations.

Fetch on miss

Most basic Cache systems are designed to be empty to begin with. When the application needs data, it tries to read it from the Cache. Since the cache is empty, it generates a “Not found” event which then can trigger a Database fetch. All subsequent reads can then fetch from the cache.

The advantage of this method is that you don’t have to populate the entire cache with data which may or may not be used. Only the required data is uploaded to cache. So you save on space and hence infrastructure cost. If you manage cache TTL (Time to live) properly, using this method you can very efficiently manage your Cache with a minimal infrastructure by keeping only the most frequently used data in the cache and nothing else.

The disadvantage of this method is that cold run for the application has is slow on response time as the data needs to get loaded.

This method is ideal for scenarios where only some parts of the data is being used frequently and occasional cache miss cost is acceptable to the users. Small cache is more important.

Pre-loaded Cache

Here you pre-load the entire cache-able data all at once. And then only update the database as and when data changes using one of the Cache Update methods (described later). This is an Anti-pattern. Loading everything into Cache could undo the performance benefits because of the added Cache management. While initially it might be inefficient, the system should eventually evict cache that not being used and come to optimum cache store.

Cache Eviction Policy

If you are using Redis, you can use a combination of TTL (Time to Live) and Expire commands to manage the Cache optimally. A good Cache Eviction policy can help you manage the size and availability of your Caching system.

Cache Update Methods

These are the standard patterns of updating your cache. Each pattern has it’s merits and demerits.

Write Through: When data changes, it is simultaneously updated to the Cache and to the Database. Advantage is consistency between Database and Cache. Disadvantage is keeping everything in the cache updated whether needed or not.

Write Around: Data is first written to the Database first to ensure that data is persisted first and then fetched into the Cache when accessed. The write logic can expire the cache when it writes to the database, so that the application knows that the data needs to be fetched when a Cache hit comes in.

Write Back: Data is first written to the cache and asynchronously updated to the database. Data loss risk is very high. So this method must be used only when data loss is affordable but data access needs to be very fast. This method can be used when the Cache layer is replicated and hence loss of one Cache server will not impact the database update.

Hopefully, this three-part article has covered areas of caching that most people are concerned with. One of the purposes of writing these articles was to make my job easier. I don’t have to point customers in different directions when caching is being discussed.