For many organisations, the cloud and cloud-native application refactoring is attractive. This is often due to the belief that it will reduce complexity and risk for them, when compared to running their own DCs. The theory being that public cloud architecture is simpler.
By going all in, however, many modern “cloud-native” applications are built upon a multitude of solutions, services and elements. This could be anything from a third party PaaS / SaaS provider for ID management, to “rolling your own” caching and search solution. It could even be simply implementing a broad set of management tooling for code and infrastructure automation.
The diagram below represents the technologies involved in one such solution. It’s clearly a highly distributed application with dependencies across many different platforms and cloud-vendors! It’s also not the only example of a solution I have seen in the new cloud-native world!
The risk is, the failure of any single one of those SaaS, PaaS or IDM platforms, automation tools or API gateways could leave an application offline and its owners potentially powerless to resolve it! Developers are exchanging the complexity of building elements into their applications natively, for the risk of distributing (out-sourcing?) them out to other cloud platforms.
Public cloud architecture isn’t always simples!
That is not to say this is not a reason to go to cloud and refactor applications to be more cloudy! The relative benefits to an organisation may far outweigh the risks. The key thing is that in any organisation, requirements from the business will always trump any expectations of simplicity or even consistency!
We are simply exchanging one set of complexities for another!
Thoughts? Feel free to discuss in the comments below!
In the spirit of these new short-form blog posts (see TekBytes: A Blogging Experiment) it’s probably appropriate that I write a quick post on a new short-form podcasting project I am working on; CloudSpotting!
My day job is as a Solutions Architect at Rackspace, where I’m fortunate enough to work for one of the most tech-agnostic global service providers around! A typical week could include me talking about or designing solutions based on VMware, Hyper-V, AWS, Azure, GCP, OpenStack, or even just plain old dedicated servers! Add to that a swathe of security, networking and storage “stuff”, it all adds up to a pretty healthy mix.
Myself and my colleague Sai Iyer thought it would be fun to share some of our learnings and experiences in designing and operating customer solutions. What better way (we thought!), than an easy-to-consume 30 minute monthly podcast for architects and engineers… In the first episode, we discuss scaling applications for peak periods and the insane growth of Kubernetes adoption! We already have episodes planned on phishing, cyber kill-chains, encryption, automation & DevOps along with a host of other topics, so watch this space!
Just to be clear though – No Kool aid, just cool tech! 🙂
For those of you who are also regular Open TechCast listeners, this doesn’t mean I am changing lanes in any way, there will just be more of my dulcet tones available on your favourite podcatcher (which may or may not be a good thing!).
Where can I find it?
If you want to catch the first episode, just search for “CloudSpotting” on iTunes or Stitcher, or catch the show on Soundcloud here:
I don’t know about you, but some of my best and worst ideas come to me when I’m in the shower… it’s quite possible this may be the latter, but let’s see where it goes!
For those of you who are either regular readers of this blog, or perhaps even know me in the “walking, talking flesh sacks” world, you will probably have noticed I’m prone to long-form communication; whether it’s writing, or indeed speaking!
Due to many reasons I won’t bore you with today (but maybe later!), life has been spectacularly busy the last few months. This has led to something which I want to correct; missing out the enjoyable act of blogging here!
What’s the plan, Stan?
In response I am going to try a little experiment based on the theory of “little and often”.
In addition to my traditional “epic saga” posts, I will be producing a new post series I’m calling #TekBytes. Not quite Twitter-style microblogging, but more regular, bite-sized chunks of content. No more than a few paragraphs or a couple of hundred words per post, based on observations and challenges I see day to day in my role as a multi-cloud solutions architect.
That doesn’t mean it will all be cloudy of course, just whatever comes to mind and I can get down into a post in a few minutes, possibly even from my phone! Some of them might even only be questions for you, the readers!
And before you ask… of course there will still be terrible memes! 😀
Thoughts? Feedback? Make yourself heard using the comments below!
Whether it’s the IEEE, the ISO or any other, we live in a world governed by standards. This has the positive impact in allowing interoperability of devices and elements, but at the same time has the unfortunate side effect of hampering the development of new technologies which conflict with those standards, even if their adoption would ultimately provide a better outcome for everyone!
At the same time, many organisations (read: vendors) opt out of these standards and introduce their own. This is great for the vendor as it is tailored to their requirements and products, but it doesn’t help the customer or their lowly sysadmin who has to then implement a load of additional tooling to manage these products. Take S3 as an example; AWS took one look at what was out there in the market, decided that none of the standards met their requirements, so wrote their own!
The key seems to me to be finding a balance, where you implement a standard, but make it extensible, such that individual vendors can add additional data or functionality over and above the baseline. This means that you can always support the “lowest common denominator” for everyone.
So what is Swordfish?
Funnily enough, the folk from SNIA (The Storage Networking Industry Association) have implemented precisely this with one of their latest standards releases, Swordfish. Specifically, this defines the standards for APIs used to manage storage devices in a consistent fashion, regardless of vendor or indeed storage class (for example software based hyper-converged solutions are supported by it, as well as block, file, object, etc!).They have achieved this by taking the existing SMI-S standards and refactoring them into a simplified model which is client, not vendor oriented, and based on a REST API model, JSON (the current industry favourite for almost all data interchange) and OData. Not only that, but they have achieved this and agreed the standards with their many members in less than 12 months. By comparison to your average RFC from the IEEE that’s lightning fast! 😮
Now this is not to say that your typical vendor is going to throw out everything they have today, but if they begin to run these APIs in parallel, I could see this eventually becoming the defacto standard for all storage management. In addition, SNIA have confirmed that if 2-3 or more vendors have a requirement for the same additional fields (which they will initially have to implement via extensions), then SNIA will ratify them within weeks. Truly an agile methodology for standards!
The Tekhead Take
This seems to me to be a pragmatic approach to a difficult problem. Keeping vendors happy, whilst trying to make life easier for storage consumers and administrators by bringing storage management into the twenty-first century!
Despite being a relatively dry subject matter, I was actually quite interested and impressed with this innovation! People will still need dedicated local storage for many years to come, and these standards will help to enable them to manage storage in a more consistent fashion. Who knows, it may even promote more competition!
Want to Know More?
I was fortunate enough to meet the team from SNIA last year at their Colorado HQ, with Storage Field Day 13. One of the speakers (industry veteran Rob Peglar) also recently appeared as a guest on the Storage Unpacked podcast – an episode well worth a listen too!
Disclaimer/Disclosure: My flights, accommodation, meals, etc, at Storage Field Day 13 were provided by Tech Field Day, but there was no expectation or request for me to write about any of the vendors products or services and I was not compensated in any way for my time at the event.