Cloud – Martijn Veldkamp

mei 30, 2018

Software as an Onion (SaaO)

Software is like an onion. Your team’s code is one “layer” in this onion. There are layers below you (which you rely on), and layers above you (which rely on you).

Of course, unlike an onion in real life, all the layers in this onion are continuously changing. New features, bug fixes, performance optimizations, etc.

In a good architecture, the effect of change flows in exactly one direction: up. You can only break layers above you, not below. This implies that the deeper you are in the onion, the greater the responsibility. Any little change can ripple upward in unexpected ways, because there’s a deep intertwining–a dependency.

It’s also like the princess and the pea; even the tiniest change can make stuff higher in the stack uncomfortable; you never know what behaviors / bugs / etc. the upper layers are relying on.

You can try to avoid breaking stuff at compile time (e.g. changing an API in an incompatible way). Beyond that, you can also run all the unit tests, get code reviews from peers and/orrelevant dependent teams, etc. Isn’t that good enough?

Alas, no. The nature of human fallibility is, things aren’t perfect, and if you plan for them to be perfect, you’ve made an imperfect plan. There will always be bugs, and bugs in lower layers can reach WAY up the stack to hose features and team way above them. This is true of everything even hardware: remember the Intel Meltdown and Spectre bugs?

The only “bullet proof” world is one where teams and services are totally independent.

Unfortunately, this isn’t possible when you have to share. Which we all do of lots of stuff. Housing and hosting, network, VMs, Containers, DB schema’s, Development stacks or even Amazon solutions.

oktober 6, 2014januari 3, 2017

Cloud reliabilty

Reliability is often attributed as one of the reasons some organizations are wary of the cloud.

Last week, Amazon, Rackspace and IBM had to “reboot” their clouds to deal with maintenance issues with the Xen hypervisor. Details were scarce but it was pretty quickly established that an unspecified vulnerability in the Xen hypervisor was the issue.

The vulnerability, discovered by researcher Jan Beulich, concerned Xen hypervisor, open-source technology that cloud service providers use to create and run virtual machines. If exploited the vulnerability would have allowed malicious virtual machines to read data from or crash other virtual machines as well as the host server.

Not all providers had to reboot their clouds to upgrades or maintenance. Google and EMC VMware support the notion of live migration, which keeps internal changes invisible to users and avoids these Xen reboots and Microsoft uses (customized) Hyper V so they did not have that vulnerability.

It is interesting to see what “uptime” means in this context. In many reports of this nature, “uptime” doesn’t take into account “scheduled downtime.” And that could very well be the case here, as well. If one does a little bit of math:

99.9% uptime is 8.77 hours of downtime per year
99.99% uptime is 52.60 minutes of downtime per year
99.999% uptime is 5.26 minutes of downtime per year

Although some users complained about the outage most where complaining about (the lack of) the providers’ communications.

Cloud providers cannot be considered as a black box anymore. As an architect we need to know the limitations of the architectural components the provider uses such as Xen. We need to know how often these kinds of reboots have occurred, and how the provider handles transparent maintenance.

We also need to consider the lines of communications. Providers often drop the ball here. People are often unhappy because they didn’t get much (or any) heads-up about the reboot, not about the reboots itself.

We should remember that outages and other disruptions are few and far between these days, so these rare event get extra media attention.

september 18, 2014januari 3, 2017

Cloud adoption! Do you have a strategy?

As conversations about the Cloud continues to focus on IT’s inability at adoption (or the gap between IT and Business), organizations outside of IT continue their cloud adoption. While many of these efforts are considered Rogue or Shadow IT efforts and are frowned upon by the IT organization, they are simply a response to a wider problem.

The IT organization needs to adopt a cloud strategy, a holistic one is even better. However, are they really ready for this approach? There are still CIOs who are resisting cloud.

A large part of the problem is that most organizations are still in a much earlier state of adoption.

Common hurdles are

The mindset : “critical systems may not reside outside your own data center”
Differentiation: “our applications and services are true differentiators”
Organizational changes : “moving to cloud changes how our processes and governance models behave”
Vendor management : “we like the current vendors and their sales representative”

In order to develop a holistic cloud strategy, it is important to follow a well-defined process. Plan Do Check Act fits just about any organization:

Assess: Provide a holistic assessment of the entire IT organization, applications and services that are business focused, not technology focused. Understand what is differentiating and what is not.

Roadmap: Use the options and recommendations from the assessment to provide a roadmap. The roadmap outlines priority and valuations .

Execute: For many, it is important to start small because of the lower risk and ramp up were possible.

Re-Assess & Adjust: As the IT organization starts down the path of execution, lessons are learned and adjustments needed. Those adjustments will span technology, organization, process and governance. Continual improvement is a key hallmark to staying in tune with the changing demands.

Today, cloud is leveraged in many ways from Software as a Service (SaaS) to Infrastructure as a Service (IaaS). However, it is most often a very fractured and disjointed approach to leveraging cloud. Yet, the very applications and services in play require that organizations consider a holistic approach in order to work most effectively.

juni 30, 2014januari 3, 2017

The Cloud has landed! It’s become Foggy

We’re about to go back once again in the circle to decentralize and give a greater role to local storage and computing power.

It depends on the nature and the amount of data that needs to be stored and it’s process demands. With the enormous rise of the amount of data because of the ‘Internet of Things’ the nature of the data is becoming more and more diffuse. These developments lead to yet another revolution in data area: The Fog.

Smarter? Or gathering more data?

More and more devices are equipped with sensors; cars, lampposts, parking lots, windmills, solar power plants and from animals to humans. Many of these developments are currently still in the design phase, but it will not be long before we live in smart homes in smart cities and we are driving our cars by smart streets wearing our smart tech.

Everything around us is ‘getting smarter’ / gathers more data. But where is that data stored, and why? Where is all that data processed into useful information? The bandwidth of the networks we use, grows much slower than the amount of data that is send through it. This requires thinking about the reason to store data (in the cloud).

If you want to compare data from many different locations, for instance data from sensors in a parking lot via an app where the nearest free parking space is, then the cloud is a good place to process the information. But what about the data that can even better be handled locally?

Data Qualification

The more data is collected, the more important it will be to determine the nature of the data is and what needs to be done with it. We need to look at the purpose of the collected data. For example: If the data is used for ‘predictive maintenance’, which monitors something so that a timely replacement or preventive maintenance can take place, it does not always make sense to send the data to the cloud.

Another example is the data that is generated by security cameras. These typically show 99.9% of the time an image of room/space that has not changed. The interesting data is the remaining 0.1% where there is something to see. The rest can be stored locally, or even not at all. This filtering of useful and useless data calls again for local power.

This decentralization of computing power and storage is a recent trend that Cisco calls ‘fog computing’. With distributed intelligence an often more effective action can be taken in response to the collected data, and unnecessary costs of bandwidth and storage can be avoided. This is a development that goes very well with the transition to the cloud.

Cisco

Fog Computing is a paradigm that extends Cloud computing and services to the edge of the network. Similar to Cloud, Fog provides data, compute, storage, and application services to end-users. The distinguishing Fog characteristics are its proximity to end-users, its dense geographical distribution, and its support for mobility. Services are hosted at the network edge or even end devices such as set-top-boxes or access points. By doing so, Fog reduces service latency, and improves Quality of Service (QoS), resulting in superior user-experience. Fog Computing supports emerging Internet of Everything (IoE) applications that demand real-time/predictable latency (industrial automation, transportation, networks of sensors and actuators). Thanks to its wide geographical distribution the Fog paradigm is well positioned for real time big data and real time analytics. Fog supports densely distributed data collection points, hence adding a fourth axis to the often mentioned Big Data dimensions (volume, variety, and velocity).

Unlike traditional data centers, Fog devices are geographically distributed over heterogeneous platforms, spanning multiple management domains. Cisco is interested in innovative proposals that facilitate service mobility across platforms, and technologies that preserve end-user and content security and privacy across domains.

The future? It will be hybrid with foggy edges.