In this guest post, Neil Briscoe, CTO of hybrid cloud platform provider 6point6 Cloud Gateway, sets about busting some common cloud myths for enterprise IT buyers
The cloud provides endless opportunity for businesses to become more agile, efficient and – ultimately – more profitable. However, the hype around cloud has made firms so desperate for the action, they’ve become blinded to the fact it might not be the right move for every company.
Many firms get sucked into the benefits of the cloud, without truly understanding what the cloud even is. I mean, would you buy a car without knowing how to drive it?
The eight fallacies of distributed computing guided many leaders into making the right decision for their business when adopting new systems. However, as the cloud continues to evolve, it can be hard to keep up.
With this in mind, here are some of commonly recurring myths that need to be busted about cloud, so businesses can make sound decisions on what is right for them.
Myth one – You have to go all-in on cloud
As with any hyped innovation, cloud is being positioned by many as a ‘fix all solution’ and somewhere that businesses can migrate all their systems to in one swoop.
In reality, many services are at different stages of their life cycle, and not suitable for full migration, and running legacy systems are no bad thing.
It’s important that each system is fit for purpose, so shop around and see exactly which one fits with your strategic roadmap. By trying to fit a square peg in a round hole, you open yourself up to all sorts of security and operational issues.
Myth two – Cloud is cheaper than on-premise
Datacentres are notoriously expensive but the hidden costs in maintaining a cloud infrastructure can be deceptively high. Don’t get distracted by the desirably low initial CAPEX and onboarding costs for migrating to the cloud, as the ongoing OPEX can shoot you in the foot long-term.
Public cloud service providers like AWS are now being much more transparent with their Total Cost of Ownership (TCO) calculator, and the numbers are quite accurate as long as you have discipline. This in turn is reducing the need for enterprises to invest in large capital expenditures and means they only pay for what you need and use.
By having a long-term plan and understanding where, why and how the cloud will benefit your business, this will – in-turn – reduce your costs. Migrating the whole datacentre will not.
Myth three – Cloud is more secure than on-premise
On-premise datacentres are clear. You have a door to go in and out of, and you can have a reasonable grasp of where your external perimeter is, and then secure it. In the cloud, there are infinite doors and windows for a malicious actor to exploit, if not secured properly.
Cloud providers give you the tools to secure your data and infrastructure probably better than you can with on-premise datacentre tools, as long as they’re used correctly.
It’s very easy to build a service and make it completely public-facing without having any resilience or security at all. Don’t assume that all cloud providers will create such high levels of security in the architecture “by default”. Sometimes you must dig deep and truly understand what is happening under the hood.
Myth four – One cloud provider is all you need
Don’t be afraid to go multi-cloud. Each system is different, and you have the power to choose the best-of-breed system for all workloads, even if this means using more than one provider.
As cloud is relatively new, people are still experimenting and figuring out what suits them best. By going multi-cloud, enterprises aren’t restricted to one particular operator and can get best-for-the-job services without sacrificing on agility. Never sacrifice on agility. You can have your cake and eat it.
Myth five – It is better to buy, not build
Building a private network and connectivity platform in the cloud sounds desirable; you build the best platform to serve your requirements without answering to an external vendor. However, building your own network isn’t as easy as 1,2,3 and once you’ve built it, maintaining it is the hardest step.
Talent is in high demand, so ensuring you can keep your talent in house to keep developing and improving your network without letting them escape is an ongoing challenge. It’s a task to ensure continuity.
By “buying”, it’s possible to remove the headache of connectivity, security and network agility of a potentially complex architecture and will allow enterprises to focus on the actual digital transformation itself without draining resources for, what is becoming, a commodity IT item.
In closing, while cloud isn’t a new innovation, enterprises and suppliers alike are continuously developing and understanding how it can benefit business.
Enterprises need to de-sensitise themselves from the hype and investigate exactly how and why the cloud will improve efficiency, competitiveness and reduce costs.
Cloud is changing every day and everyone’s experiences are different, but keeping your eyes and ears open to the numerous benefits but also the threats it can create will ensure that enterprises use the cloud effectively.
In this guest post, Chris Hodson, chief information security officer for Europe, Middle East and Africa (EMEA) at internet security firm Zscaler, takes a closer look at why cloud security remains such an enduring barrier to adoption for so many enterprises.
Cloud computing is growing in use across all industries. Multi-tenant solutions often provide cost savings whilst supporting digital transformation initiatives, but concerns about the security of cloud architectures persist.
Some enterprises are still wary using cloud because of security concerns, even though the perceived risks are rarely unique to the cloud. Indeed, my own research shows more than half of the most appropriate vulnerabilities with cloud usage (identified by the European Union Agency for Network and Information Security (ENISA)) would be present in any contemporary technology environment.
Weighing up the cloud security risk
To establish the risks, beneﬁts and suitability of cloud, we need to define the various cloud deployments, and operational and service models in use today and in the future.
A good analogy is that clouds are like roads; they facilitate getting to your destination, which could be a network location, application or a development environment. No-one would enforce a single, rigid set of rules and regulations for all roads – many factors come into play, whether it’s volume of trafﬁc, the likelihood of an accident, safety measures, or requirements for cameras.
If all roads carried a 30 mile per hour limit, you might reduce fatal collisions, but motorways would cease to be efﬁcient. Equally, if you applied a 70 mile per hour limit to a pedestrian precinct, unnecessary risks would be introduced. Context is very important – imperative in fact.
The same goes for cloud computing. To assess cloud risk, it is vital that we define what cloud means. Cloud adoption continues to grow, and as it does, such an explicit delineation of cloud and on-premise will not be necessary.
Is the world of commodity computing displacing traditional datacentre models to such an extent that soon all computing will be elastic, distributed and based on virtualisation? On the whole, I believe this is true. Organisations may have speciﬁc legacy, regulatory or performance requirements for retaining certain applications closer-to-home, but these will likely become the exception, not the rule.
Consumers and businesses continue to beneﬁt from the convenience and cost savings associated with multi-tenant, cloud-based services. Service-based, shared solutions are pervasive in all industry verticals and the cloud/non-cloud delineation is not a suitable method of performing risk assessment.
Does cloud introduce new cloud security risks?
According to the International Organisation for Standardisation (ISO), risk is “the effect of uncertainty on objectives.” So, does cloud introduce new forms of risk which didn’t exist in previous computing ecosystems? It is important that we understand how many of these are unique to the cloud and a result of the intrinsic nature of cloud architecture.
Taking an ethological or sociological approach to risk perception, German psychologist Gerd Gigerenzer asserts that people tend to fear what are called “dread risks”: low-probability, high-consequence but with a primitive, overt impact. In other words, we feel safer with our servers in our datacentre even though we would (likely) be better served to leave security to those with cyber security as their core business.
The cloud is no more or less secure than on-premise technical architecture per se. There are entire application ecosystems running in public cloud that have a defence-in-depth set of security capabilities. Equally, there are a plethora of solutions that are deployed with default conﬁgurations and patch management issues.
Identifying key cloud security risks
ENISA, which provides the most comprehensive and well-constructed decomposition of what it considers the most appropriate vulnerabilities with cloud usage, breaks cloud vulnerabilities into three areas:
- Policy and organisational – this includes vendor lock-in, governance, compliance, reputation and supply chain failures.
- Technical – this covers resource exhaustion, isolation failure, malicious insider, interface compromise, data interception, data leakage, insecure data deletion, denial of service (DDoS) and loss of encryption keys
- Legal – such as subpoena and e-discovery, changes of jurisdiction, data protection risks and licensing risks
The fact is, however, that most of these vulnerabilities are not unique to the cloud. Instead, they are the result of a need for process change as opposed to any technical vulnerability. The threat actors in an on-premise and public cloud ecosystem are broadly similar.
An organisation is idiomatically only as strong as its weakest link. Whilst it is prudent to acknowledge the threats and vulnerabilities associated with public cloud computing, there are a myriad of risks to the conﬁdentiality, integrity and availability which exist across enterprise environments.
Ultimately, when it comes to the cloud it’s all about contextualising risk. Businesses tend to automatically think of high profile attacks, such as the Spectre meltdown, but the chances of this type of attack happening is extremely low.
Organisations undoubtedly need to assess the risks and make necessary changes to ensure they are compliant when making the move to the cloud, but it is wrong to assume that the cloud brings more vulnerabilities – in many situations, public cloud adoption can improve a company’s security posture.
In this guest post, Allan Brearley, cloud practice lead at IT services consultancy ECS, advises enterprises to start small to achieve big change in their organisations with cloud.
The success of Elon Musk’s Falcon Heavy rocket (and its subsequent return to earth) wowed the world. Imprinted on everyone’s memory, thanks to the inspired addition of the red Tesla Roadster as its payload blasted out Bowie’s Life on Mars on repeat, the mission demonstrates the “start small, think big, learn fast” ethos evangelised by that other great American innovator, Steve Jobs.
And this “start small, think big” ethos can equally be applied to cloud-based transformation projects.
Making the right decisions at the right time is key. Musk understands this, expounding the need to focus on evidence-based decision making to come up with a new idea or solve a problem.
While thinking big about rocket innovation, he committed to three attempts, setting strict boundaries and budgets for each phase. This meant he didn’t waste cash or resources on something that wouldn’t work.
Coming back down to earth, IT teams tasked with moving workloads to the cloud (rather than putting payloads into space) can learn a lot from this approach to innovation.
For organisations not born in the cloud, the decision to bring off-premise technologies into the mix throws up some tough questions and challenges. As well as the obvious technical considerations, there are other hoops to jump through from a cost, risk, compliance, and regulatory point of view, to ensuring you have suitably qualified people in place.
Lay the groundwork for cloud
It is quite common for highly-regulated businesses with complex infrastructure to enter a state of analysis paralysis at the early stages of a cloud transformation due to the sheer scale and difficulty of the task ahead.
Instead of pausing and getting agreement on a “start small” strategy, they feel compelled to bite off more than they can chew and “go large”.
At this point, enterprises often go into overdrive to establish the business case, scope the project, and formulate the approach all in one fell swoop. But this is likely to result in the cloud programme tumbling back to earth with a bang.
It is simply impossible on day one to plan and build a cloud platform that will be capable of accepting every flavour of application, security posture and workload type.
As with any major transformation project, the cultural and organisational changes will take considerable time and effort. Getting your priorities straight at the outset and straightening out your people, process, and technology issues is critical. This involves getting closer to your business teams, being champions for change, and up-skilling your workforce.
A shift in cloud culture
Moving to the cloud often heralds a shift in company culture, and it’s important to consider up front how the operating model will adapt and what impact this will have across the business.
Leadership needs to prepare for the shift away from following traditional waterfall software development processes to embracing agile and DevOps methodologies that will help the business make full use of a cloud environment, while speeding up the pace of digital transformation.
Cloud ushers in a new way of working that cuts swathes across enterprises’ traditional set-up of infrastructure teams specialising in compute, network, and storage etc. Care must be taken to ensure these individuals are fully engaged, supported, trained and incentivised to ensure a successful outcome.
Start small to achieve big things
Starting with a small pathfinder project is a good strategy, as it allows you to lay the foundations for the accelerated adoption of cloud downstream, as well as for migration at scale – assuming this is the chosen strategy.
Suitable pathfinder candidates might be an application currently hosted on-premise that can be migrated to the cloud, or a new application/service that is being developed in-house to run in the cloud from day one.
Once the pathfinder project is agreed upon, the race is on to assemble a dream team of experts to deliver a Minimum Viable Cloud (MVC) capability that can support the activity; this team will also establish the core of your fledgling cloud Centre of Excellence (CoE).
Once built, the MVC can be extended to support more complex and demanding applications that require more robust security measures.
The CoE team will also be on hand to support the construction of the business case for a larger migration. This includes assessing suitable application migration candidates, and grouping them together into virtual buckets, based on their suitability for cloud.
These quick wins will help to convert any naysayers and secure stakeholder buy-in across the business ahead of a broader cloud adoption exercise. They are also a powerful way to get the various infrastructure teams on side, providing as they do a great platform for re-skilling and opening up fresh career opportunities to boot.
In summary, taking a scientific approach to your cloud journey and moving back and forth between thinking big and moving things forward in small, manageable steps will help enable, de-risk and ultimately accelerate a successful mass migration.
As both the space race and the cloud race heat up, it’s good to remember the wise words of the late great Steve Jobs: “Start small, think big. Don’t worry about too many things at once. Take a handful of simple things to begin with, and then progress to more complex ones. Think about not just tomorrow, but the future. Put a ding in the universe.”
To coincide with the first day of the Google Cloud Next 2018 conference (taking place from 24-26 July) in San Francisco, John Jainschigg, content strategy lead at enterprise systems monitoring software provider Opsview shares his views on what datacentre operators can learn from the search giant’s site reliability engineers.
The noughties witnessed many experimental breakthroughs in technology, from the introduction of the iPod to the launch of YouTube. This era also saw a fresh-faced Google, embarking on a quest to expand its portfolio of services beyond search. Much like any highly ambitious, innovative technology initiative, the firm encountered a number of challenges along the way.
In response, Google began evolving a discipline called Site Reliability Engineering (SRE), about which they published a very useful and fascinating book in 2016. SRE and DevOps share a lot of conceptual and an increasing amount of practical DNA; particularly true since cloud software and tooling have now evolved to enable ambitious folks to begin emulating parts of Google’s infrastructure using open source software like Kubernetes.
Google has used the statement “class SRE implements DevOps” to title a new (and growing) video playlist by Liz Fong-Jones and Seth Vargo of Google Cloud Platform, showing how and where these disciplines connect, while nudging DevOps practitioners to consider some key SRE insights, including the following.
- The normality of failure: It is near impossible to produce 100% uptime for a service. Therefore, expecting such a high success-rate is expensive, and pointless, given the existence of masking error rates among your service’s dependencies.
- Ensure your organisation agrees on its Service Level Indicators (SLIS) and Objectives (SLOs): Since failure is normal, you need to agree across your entire organisation what availability means; what specific metrics are relevant in determining availability (SLIs); and what acceptable availability looks like, numerically, in terms of these metrics (SLOs).
- Create an ‘error budget’ using agreed-upon SLOs: SLO is used to define what SREs call the “error budget” which is a numeric line in the sand (such as minutes of service downtime acceptable per month). The error budget is used to encourage collective ownership of service availability and blamelessly resolve disputes about balancing risk and stability. For example, if programmers are releasing risky new features too frequently, compromising availability, this will deplete the error budget. SREs can point to the at-risk error budget, and argue for halting releases and refocusing coders on efforts to improve system resilience.
The error budget point is important because it lets the organisation as a whole effectively balance speed/risk with stability. Paying attention to this economy encourages investment in strategies that accelerate the business while minimising risk: writing error- and chaos-tolerant apps, automating away pointless toil, advancing by means of small changes, and evaluating ‘canary’ deployments before proceeding with full releases.
Monitoring systems are key to making this whole, elegant tranche of DevOps/SRE discipline work. It’s important to note (because Google isn’t running your datacentre) this has nothing to do with what kind of technologies you’re monitoring, with the processes you’re wrangling, or with the specific techniques you might apply to stay above your SLOs. In short, it makes just as much sense to apply SRE metrics discipline to conventional enterprise systems as it does to twelve-factor apps running on container orchestration.
So with that in mind, these are the main things that Google SRE can teach you about monitoring:
- Do not over-alert the user: Alert exhaustion is a real thing, and paging a human is an expensive use of an employee’s time.
- Be smart by efficiently deploying monitoring experts: Google SRE teams with a dozen or so members typically employ one or two monitoring specialists. But they don’t busy these experts by having them stare at real-time charts and graphs to spot problems: that’s a kind of work SREs call ‘toil’ — they think it’s ineffective and they know it doesn’t scale.
- Clear, real-time analysis, with no smoke and mirrors: Google SREs like simple, fast monitoring systems that help them quickly figure out why problems occurred, after they occurred. They don’t trust magic solutions that try to automate root-cause analysis, and they try to keep alerting rules in general as simple as possible, without complex dependency hierarchies, except for (rare) parts of their systems that are in very stable, unambiguous states.
- The value of far-reaching “white box” monitoring: Google likes to perform deeply introspective monitoring of target systems grouped by application. Viewing related metrics from all systems (e.g., databases, web servers) supporting an application lets them identify root causes with less ambiguity (for example, is the database really slow, or is there a problem on the network link between it and the web host?)
- Latency, traffic/demand, errors, and saturation: Part of the point of monitoring is communication, and Google SREs strongly favour building SLOs (and SLAs) on small groups of related, easily-understood SLI metrics. As such, it is believed that measuring “four golden signals” – latency, traffic/demand, errors, and saturation – can help pinpoint most problems, even in complex systems such as carrier orchestrators with limited workload visibility. It’s important to note, however, that this austere schematic doesn’t automatically confer simplicity, as some monitoring makers have suggested. Google notes that ‘errors’ are intrinsically hugely diverse, and range from easy to almost impossible to trap; and they note that ‘saturation’ often depends on monitoring constrained resources (e.g., CPU capacity, RAM, etc.) and carefully testing hypotheses about the levels at which utilisation becomes problematic.
Ultimately, an effective DevOps monitoring system must entail far more than do-it-yourself toolkits. While versatility and configurability are essential, more important is the ability of a mature monitoring solution to provide distilled operational intelligence about specific systems and services under observation, along with the ability to group and visualise these systems collectively, as business services.
In this guest post Paul Timms, managing director of IT support provider MCSA, shares his thoughts on why enterprises can ill-afford to overlook the importance of business continuity and disaster recovery.
With downtime leading to reputational damage, lost trade and productivity loss, organisations are starting to realise continuity planning and disaster recovery are critical to success.
Business continuity needs to be properly planned, tested and reviewed in order to be successful. For most businesses, planning for disaster recovery will raise more questions than answers to begin with, but doing the hard work now will save a lot of pain in the future.
Ascertain the appetite for risk
All businesses are different when it comes to risk. While some may view a ransomware attack as a minor inconvenience, dealt with by running on paper for a week while they rebuild systems, whereas others view any sort of downtime as unacceptable.
The individual risk appetite of your organisation will have a significant impact on how you plan and prepare for business continuity. You will need to consider your sector, size, and attitude towards downtime, verses cost and resources. Assessing this risk appetite will let you judge where to allocate resources, and focus your priorities.
Plan, plan and plan some more
To properly plan for disaster recovery, it is critical to consider all aspects of a business continuity event, together with the impact of it, and how to mitigate these.
For example, if power goes down in the organisation’s headquarters, so will the landline phones, but mobiles will still be functional. A way to mitigate this impact would be to reroute the office phone number to another office or a mobile at headquarters. To do that you need to consider where you store the information about how to do that, and who knows where it is.
This is just one example. You need to consider all the risks, and all the technology and processes that you use. Consider the plan, the risk, the solution and where you need to invest and strengthen your plan to ensure your business can still function in the event of a disaster.
Build in blocks and test rigorously
Ideally IT solutions will be built and tested in blocks, so you can consider the risks and solutions in a functional way. You can consider for example your network, WAN/LAN, storage and data protection.
Plans for each then need to be tested in a rigorous way with likely scenarios. What if, for example, a particular machine fails? What happens if the power supply cuts out? What happens in the case of a crypto virus? Do you have back-ups? Are they on site? Do you have a failover set-up in case of system failure? Is the second system on site or in a completely different geography? What do I with my staff – can they work from home? Are there enough laptops?
These will drive out and validate (or not) assumptions on managing during a business continuity event. For example if your company is infected with a crypto virus and has infected the main servers, it will also have replicated across to your other sites, therefore your only option is to restore from back-ups or have a technology solution that allows you to roll back before the virus was unleashed.
Cloud is not the only answer
It can be tempting to think cloud can solve all the problems, but that is not always the case. Data in the cloud is not automatically backed up and is not necessarily replicated to a second site. These are options on some public cloud services, but they are often expensive and under used, as a result.
Despite being cloud-based, a company’s Office365 environment can still get a virus and become corrupted. If you have not put the IT systems in place to back that data up, then it will be lost. If for example, the cloud goes down, you need to consider a failover system.
The interesting part of this is the public cloud doesn’t go down very often, but when it does it is impossible to tell you how long it will be out of action for. Businesses must therefore consider when to invoke disaster recover in that instance.
Know your core systems
One solution that some companies adopt is running core systems and storage on infrastructure that they know and trust. This means knowing where it is and what it is, so it meets their performance criteria. Businesses also consider how this system is backed up including what network it is plugged into, ensuring it has a wireless router as standby, that the failover system is at least 50 miles away on a separate IP provider, that the replication is tested and that the data protection technology works and is tested.
This gives business much better knowledge and control in a business continuity event such as a power outage. Businesses can get direct feedback about the length of outage meaning they have better visibility and ability to make the right decisions.
Plan and prioritise
When making a plan you need to consider the risks and your objectives. A useful approach towards technology can be to consider how it can help mitigate these risks and help you meet your objectives. When considering budget, there is no upper limit to what you can spend, instead focus on your priorities and then have the board sign them off.
Spending a day brainstorming is a good way of working out what concerns your organisation the most and what will have the most detrimental impact should it go wrong. Needless to say, something that has a high risk of impact needs to be prioritised. In terms of the executor of any business continuity plan, as the saying goes, don’t put your eggs in one basket – involving numerous people and hence ensuring more than one person is trained in the business continuity plan will significantly mitigate the impact of any event.
In this guest post, Eran Kinsbruner, lead technical evangelist at DevOps software supplier Perfecto, talks about why success in agile software development hinges on getting the people, processes and technology elements all in alignment
In a super-charged digital environment where competition is fierce and speed and quality are crucial, many organisations are incorporating DevOps practices (including continuous integration and continuous delivery) into their software development processes.
These companies know software is safer when people with complementary skills in technical operations and software development work together, not apart. However, to keep succeeding organisations must be committed to on-going self-evaluation and embrace the need to change when necessary.
Keeping it fresh is key to success – and for us, this comes from three primary areas; people, processes and technology.
The people part of the DevOps equation
The developer’s role is constantly evolving, and functions that were once owned by testers or quality assurance (QA) teams now fall firmly under their remit. This means new skills are needed, and it’s important that organisations are committed to upskilling their developers.
For some, this means facilitating the mentoring of testers by highly qualified developers. And for others it means considering a change in software development practices to include Acceptance Test Driven Development (ATDD), which promotes defining tests as code is written.
Test automation becomes a core practice during feature development rather than afterwards. Depending on team skills, implementing Behaviour Driven Development (BDD) (which implements test automation with simple English-like syntax) serves less technical teams extremely well. There are bound to be blind spots between developer, business and test personas – and choosing development practices matched to team skills can contribute to accelerating development velocity.
Leadership is another critical aspect of success in DevOps and continuous testing. Diverse teams and personas call for strong leadership as a unifying force, and a leader’s active role in affecting change is crucial. Of course, part of leadership is to enforce stringent metrics and KPIs which help to keep everyone on track.
The importance of process
Teams must always work to clean up their code and to do it regularly. That includes more than just testing. Code refactoring (the process of restructuring computer code) is important for optimal performance, as is continually scanning for security holes.
It also includes more than just making sure production code is ‘clean’. It’s crucial to ‘treat test code as production code’ and maintain that too. Good code is always tested and version controlled.
Code can be cleaned and quality ensured in several ways. The first is through code reviews and code analysis; making make sure code is well-maintained and there are no memory leaks. Using dashboards, analytics and other visibility enablers can also help power real-time decision making which is based on concrete data – and can help teams deliver quicker and more accurately.
Finally, continuous testing by each feature team is important. Often, a team is responsible for specific functional components along with testing, and so testing code merges locally is key to detect issues earlier. Only then can teams be sure that, once a merge happens into the main branch, the entire product is not broken, and that the overall quality picture is kept consistent and visible at all times.
Let’s talk technology
When there is a mismatch between the technology and the processes or people, development teams simply won’t be able to meet their objectives
A primary technology in development is the lab itself. A test environment is the foundation of the entire testing workflow, including all continuous integration activities. It perhaps goes without saying that when the lab is not available or unstable, the entire process breaks.
For many, the requirement for speed and quality means a shift to open-source test automation tools. But, as with many free and open-source software markets, a plethora of tools complicates the selection process. Choosing an ideal framework isn’t easy, and there are material differences between the needs of developers and engineers, which must be catered for.
A developer’s primary objective is for fast feedback for their localised code changes. Frameworks like Espresso, XCUITest and JSDom or Headless Chrome Puppeteer are good options for this.
A test engineer, on the other hand, concentrates on the integration of various developers into a complete packaged product, and for that, their end-to-end testing objectives require different frameworks, like Appium, Selenium or Protractor. And production engineers are executing end-to-end tests to identify and resolve service degradations before the user experience is impacted. Frameworks such as Selenium or Protractor are also relevant here but the integration with monitoring and alerting tools becomes essential to fit into their workflow.
With such different needs, many organisations opt for a hybrid model, where they use several frameworks in tandem.
People, processes and technology – together
Ultimately, we believe that only by continually re-evaluating people, processes and technology – the three tenets of DevOps – can teams achieve accelerated delivery while ensuring quality. It’s crucial in today’s hyper-competitive landscape that speed and quality go hand in hand, and so we’d advise every organisation to take a look at their own operations and see how they can be spring-cleaned for success.
In this guest post, Chip Childers, CTO of open source platform-as-a-service Cloud Foundry, makes the case for why the future of public cloud and IaaS won’t be proprietary.
Once upon a time, ‘Infrastructure-as-a-Service’ basically meant services provided by the likes of Amazon Web Services (AWS), Microsoft Azure or Google Cloud Platform (GCP), but things are changing as more open source offerings enter the fray.
This is partly down to Kubernetes, which has done much to popularise container technology, helped by its association with Docker and others, which has ushered in a period of explosive innovation in the ‘container platform’ space. This is where Kubernetes stands out, and today it could hold the key to the future of IaaS.
History in technology, as in everything else, matters. And so does context. A year in tech can seem like a lifetime, and it’s really quite incredible to think back to how things have changed in just a few short years since the dawn of IaaS.
Back then the technology industry was trying to deal with the inexorable rise of AWS, and the growing risk of a monopoly emerging in the world of infrastructure provision.
In a bid to counteract Amazon’s head start, hosting providers started to make the move from traditional hosting services to cloud (or cloud-like) services. We also began to see the emergence of cloud-like automation platforms that could potentially be used by both enterprise and service providers.
Open source projects such as OpenStack touted the potential of a ‘free and open cloud’, and standards bodies began to develop common cloud provider APIs.
As a follow on to this, API abstraction libraries started to emerge, with the aim of making things easier for developers working with cloud providers who did not just want to rely on a few key players.
It was around this time that many of the cloud’s blue-sky thinkers first began to envisage the age of commoditised computing. Theories were posited that claimed we were just around the corner from providers trading capacity with each other and regular price arbitrage.
Those predictions proved to be premature. At that time, and in the years hence, computing capacity simply wasn’t ready to become a commodity that providers could pass between each other – the implementation differences were simply too great.
That was then – but things are certainly looking different today. Although we still have some major implementation differences between cloud service providers, including the types of capabilities they’re offering, we’re seeing the way forward to an eventual commoditisation of computing infrastructure.
While even the basic compute services remain different enough to avoid categorisation as a commodity, this no longer seems to matter in the way that it once did.
That change has largely come about because of the ‘managed Kubernetes clusters’ used by most public cloud providers now.
The shift has also been happening in the private sector, with many private cloud software vendors adopting either a ‘Kubernetes-first’ architecture or a ‘with Kubernetes’ product offering.
As Kubernetes continues its seemingly unstoppable move towards ubiquity, Linux containers now look likely to become the currency of commodified compute.
There are still implementation differences of course, with cloud providers differing in the details of how they offer Kubernetes services, but the path towards consistency now seems a lot clearer than it did a decade ago.
This more consistent approach to compute now seems as inevitable as the future of IaaS, made possible by the open source approach of Kubernetes.
In this guest post, Richard Blanford, managing director of G-cloud-listed IT services provider Fordway, advises companies to weigh up the pros and cons of using SaaS and IaaS before going all-in on the cloud.
For many organisations, moving to the cloud makes complete business sense. If I set up a business now, I would run all my IT in the cloud.
But that doesn’t mean a ‘cloud for everything’ policy will work for every company. Most of us are not starting from scratch or working with a small number of relatively straightforward applications. Therefore, we need to consider carefully whether all our applications can be transferred efficiently and cost-effectively to the cloud.
The first step should always be to look for an appropriate SaaS service. This should provide:
- A suitable application that can be configured (where and if necessary) and data imported to provide comparable or better functionality to existing applications at a suitable price, paid on a metered basis, ideally per user/per month. It will ideally offer tools and communities so you can benefit from the experiences of those who’ve already implemented it.
- A supporting infrastructure which is no longer your responsibility with an appropriate, fit for purpose SLA that meets your business and operational requirements.
- The ability to easily and cost-effectively access, import and export data to other applications for analysis and business reporting.
Once you’ve identified such a service, and confirmed it offers the right resilience at the right cost, you can simply consume it, whilst monitoring to ensure you receive what you’ve signed up for.
The best analogy for SaaS billing models is that it is like turning on a tap to obtain water, rather than going to a well to collect it, before readying it for consumption through purification, for example. Good SaaS provides what you need when you need it, and you’re billed for what you use.
Assessing the cloud-use cases
Cloud is also cost-effective for non-live environments where you pay as you use. This includes disaster recovery (DR), where all servers can be held in a suspended state without incurring charges until needed, and test and development environments, where you only pay when your code runs.
All you need to provide is management. Just be aware that different cloud providers’ Platform as a Service (PaaS) offerings have different APIs, so there’s some element of provider lock-in that may come into play.
It’s more difficult to find appropriate SaaS offerings for niche applications and those that need to be customised to align with business processes. Many application providers are developing their own SaaS strategy, but these typically only support the latest version of the software, and many cannot accept customised applications or third-party add-ons.
This can be a particular problem for local authorities and the NHS, who use highly customised applications for services such as parking management, waste collection and medication prescription and management.
We’ve investigated many ‘SaaS’ offers for our customers, and all too often the vendor will simply park and maintain a dedicated version of the user’s software on a public cloud service while charging a premium price.
SaaS vs. IaaS
If SaaS is not an option, there is also IaaS to consider. You simply move your application (as-is or with minor enhancements) to operate from a cloud provider’s infrastructure. This frees you from the need to own, operate and manage the infrastructure hosting it, although you need to retain licences and support from the application provider.
There are two provisos with IaaS. First, each provider has different design rules, and you need to work through their menu of choices to find the right solution for your organisation. This requires a thorough understanding of your environment, such as how many fixed and mobile IP addresses are needed, whose DNS service will be used, how much data will go in and out of the cloud etc.
Think of it as choosing a separate hub, spokes and rim for a bicycle wheel rather than simply buying a complete wheel.
The devil’s in the detail
Many organisations don’t specify their IT to this level of detail, as once they’ve bought their infrastructure they use all the capacity available. In a cloud environment, however, everything is metered, and – unless the service can be specified extremely tightly – it may not work out cheaper than in-house provision. For example, you can reduce costs by reserving instances, but you are then locked in for one or three years, with a significant cancellation charge. A similar issue arises when buying spot instances, and these can be shut down with no notice, so aren’t suitable for business critical services.
Secondly, the cloud provider only provides hosting, including host and hypervisor patching and proactive infrastructure security monitoring. Any other patching (plus resilience, back-up, security and application support and maintenance inside the instance) need to be provided in-house or by contracting third parties. Any scaling up or down has to be done using the cloud provider’s tools, and this quickly becomes complex when most organisations have on average 40 applications. In short, managing IaaS is effectively a full-time job.
Much of this complexity can be hidden by using a managed IaaS service, where a provider handles everything from operating system provision and authentication to patching and back-up, and charges for an agreed number of instances per month. Managed IaaS services effectively offer your legacy application back to you as SaaS.
This complexity should not deter you if you are determined to transfer your applications to cloud. However, it is important to go in with your eyes open, or to find an expert to go in with you. Alternatively, if SaaS is not available and IaaS sounds like too much work at present, there is a solution: configure your IT as a private cloud. You can then continue to run it in-house with everything in place to move it to SaaS when a suitable solution becomes available.
In this guest post, Darren Watkins, managing director at colocation provider VIRTUS Data Centres, on how to help organisations take back control over their big data.
When the story broke in March that 50 million Facebook profiles were harvested for British research firm Cambridge Analytica in a major breach, questions about the misuse of personal data once again hit the headlines.
There has been a barrage of promises in response from European politicians and tech executives, vowing to do their best to tighten up controls over our data and even introduce new laws to punish blatant malpractice.
Facebook itself has been contrite, with public apologies from CEO Mark Zuckerberg and most recently the announcement of a bounty program which will reward people who find cases of data abuse on its platforms.
Using big data for good
Incidents like this undoubtedly fuel public wariness about how commercial organisations use their data, but – on the flip side – those in the technology industry know that data capture can be of enormous benefit.
From improving healthcare to powering shopping, travel and even how we fall in love, ‘big data’ is all around us and it’s here to stay. Indeed the Open Data Institute’s (ODI) recent YouGov poll of British adults revealed nearly half of people said they would share their own data – without restrictions – about their background and health preferences if it helped advance academic understanding of areas such as medicine or psychology.
However, for any organisation that operates with data there is a fine line to tread between innovation and responsibility.
There’s a big move at the moment for companies to embrace the ethos of responsible innovation. For some, this means creating products and services designed to meet humanitarian needs. Facebook’s partnership with UNICEF to better map disaster areas is a great example of this. For others it means everyone in the IT industry should move away from looking at their work from a purely technical point of view and ask how their developments may affect end-users and society as a whole.
When it comes to data applications, responsible innovation is a commitment to balancing the need to deliver compelling, engaging, products and services, with the need to make sure data is stored, processed, managed and used properly. This process starts way away from the headlines, or the CEO statements.
Preparation is key
To avoid falling victim to breaches or scandals, companies must ensure they have the right ‘building blocks’ in place. And this starts with data security.
Simple hacking is where big data shows big weakness, thanks to the millions of people whose personal details can be put at risk with any single security breach. The scope of the problem has grown considerably in a short time. It wasn’t too long ago that a few thousand data sets being put at risk by a hack was a major problem. But in September 2017, Yahoo confirmed it did not manage to secure the real names, date of birth, and telephone numbers of 500 million people. That’s data loss on an unimaginable scale, and for the public, that’s scary stuff.
This, together with the computing power needed for big data applications, puts increasing pressure on organisations’ IT and data centre strategies, and this is the challenge which most urgently needs to be overcome. Indeed, it’s not an exaggeration to say that data centre strategy could be crucial to big data’s ultimate success or failure.
For even the biggest organisations, the cost of having (and maintaining) a wholly-owned datacentre can be prohibitively high. But security concerns can mean a wholesale move to cheap, standard, cloud platforms in a hybrid model – where security may not be as advanced – also isn’t an option.
Instead, the savviest firms are turning to colocation options for their data storage needs, recognising that moving into a shared environment means that IT can more easily expand and grow, without compromising security or performance.
It’s by starting here, in the ‘weeds’ of the data centre, that companies can ensure they’ve got firm control over their biggest asset – the data they have and how they use it.
As the public grows more wary of data breaches, the pressure will (and already has) come to bear on the business community to pay more attention to securing, storing and using data in the right way. Countermeasures that used to be optional are in the process of becoming standard and increased pressure is being put on company’s IT systems and processes. For us, it’s in the datacentre where companies can take firm control – avoid the scandals and make sure that innovation is done right.
In this guest post, Jon Topper, CTO of DevOps and cloud infrastructure consultancy The Scale Factory, on how the growing maturity of Kubernetes dominated this year’s Kubecon.
KubeCon + CloudNativeCon Europe, a three day, multi-track conference run by the Cloud Native Computing Foundation (CNCF), took place in Copenhagen earlier this month, welcoming over 4,300 adopters and technologists from leading open source and cloud native communities.
The increase in popularity of container orchestrator software Kubernetes was a defining theme of this year’s show, as it moves beyond being an early adopter technology, to one that end-user organisations are putting into production in anger.
What is Kubernetes?
Kubernetes provides automation tooling for deploying, scaling, and managing containerised applications. It’s based on technology used internally by Google, solving a number of operational challenges that may have previously required manual intervention or home-grown tools.
This year the Kubernetes project graduated from the CNCF incubator, demonstrating that it is now ready for adoption beyond the early adopter communities where it has seen most use thus far.
Many of the conference sessions at the show reinforced the maturity message, with content relating to grown-up considerations such as security and compliance, as well as keynotes covering some interesting real-life use cases.
We heard from engineers at CERN, who run 210 Kubernetes clusters on 320,000 cores so that 3,300 users can process particle data from the Large Hadron Collider and other experiments.
Through the use of cluster federation, they can scale their processing out to multiple public clouds to deal with periods of high demand. Using Kubernetes to solve these problems means they can spend more time on physics and data processing than on worrying about distributed systems.
This kind of benefit was reiterated in a demonstration by David Aronchick and Vishnu Kannan from Google, who showed off Kubeflow.
This project provides primitives to make it easy to build machine learning (ML) workflows on top of Kubernetes. Their goal is to make it possible for people to train and interact with ML models without having to understand how to build and deploy the code themselves.
In a hallway conversation at the show with a member of the Kubernetes Apps Special Interest Group (sig-apps), I learned there are teams across the ecosystem working on providing higher order tooling on top of Kubernetes to make application deployment of all kinds much easier.
It will eventually be the case that many platform users won’t interact directly with APIs or command line tools at all.
This ongoing commodification of underlying infrastructure is a trend that Simon Wardley spoke about in his Friday keynote. He showed how – over time – things that we’ve historically had to build ourselves (such as datacentres) have become commoditised.
But spending time and energy on building a datacentre doesn’t give us a strategic advantage, so it makes sense to buy that service as a product from someone who specialises in such things.
Of course, this is the Amazon Web Services (AWS) model. These days we create managed databases with their RDS product instead of building our own clusters of MySQL.
At an “Introducing Amazon EKS” session, AWS employees described how their upcoming Kubernetes-as-a-Service product will work.
Amazon is fully bought into the Kubernetes ecosystem and will provide an entirely upstream-compatible deployment of Kubernetes, taking care of operating the control servers for you. The release date for this product was described, with some hand-waving, as “soon”.
In working group discussions and on the hallway track, it sounded as though “soon” might be further away than some of us might like – there are still a number of known issues with running upstream Kubernetes on AWS that will need to be solved.
When the product was announced at AWS re:Invent last year Amazon boasted (based on the results of a CNCF survey) that 63% of Kubernetes workloads were deployed on AWS.
At this conference, they came with new figures stating that the number had dropped to 57% – could that be because both Google Cloud and Microsoft’s Azure already offer such a service?
Wardley concluded his keynote by suggesting that containerisation is just part of a much bigger picture where serverless wins out. Maybe AWS is just spending more time on their serverless platform Lambda than on their Kubernetes play?
Regardless of where we end up, it’s certainly an exciting time to be working in the cloud native landscape. I left the conference having increased my knowledge about a lot of new things, and with a sense that there’s still more to learn. It’s clear the cloud native approach to application delivery is here to stay – and that we’ll be helping many businesses on this journey in the years to come.