When emerging technologies, such as blockchain, artificial intelligence (AI) and the Internet of Things converge, a ‘gestalt shift’ will occur, according to a new book. “The character of the experience will drastically change,” write Mark van Rijmenam and Dr. Philippa Ryan in Blockchain: Transforming Your Business and Our World. “All of a sudden, we can see the world through a different, more technologically advanced, lens and this opens up a completely new perspective.

“The convergence of multiple disruptive technologies will offer us new possibilities and solutions to improve our lives and create better organisations and societies, as well as build a better world all together.”

Organisations are increasingly taking the approach of exploring these technologies in tandem rather than in silos. Put simply, they all feed into each other. Pat Gelsinger, CEO of VMware, had it nailed down at the recent VMworld event. “Each [technology] is a superpower in [its] own right, but they’re making each other more powerful,” he told attendees. “Cloud enables mobile connectivity; mobile creates more data; more data makes the AI better; AI enables more edge use cases; and more edge requires more cloud to store the data and do the computing.”

For van Rijmenam, already a well-established big data thought leader, it was a natural trend. “The convergence of emerging technologies is the true paradigm shift organisations have to face,” he tells CloudTech. “Big data and blockchain have a lot in common and it will actually make data governance more importance – after all, blockchain makes data immutable, verifiable and traceable, but it does not magically turn low-quality data into high-quality data.”

This feeds into the central problem, that of data – what to do with it and how to utilise it best. But ‘twas ever thus. “When initiating your business intelligence project, you’re likely to be surprised at how bad your raw material – data – really is,” wrote Dan Pratte in TechRepublic. “You’ll discover that if you’re going to be serious about business intelligence, you’re going to have to get very serious (their emphasis) about data quality as well.” The article publication date? May 30 2001.

Today, artificial intelligence is redefining business intelligence at a rapid rate. Take the recent analysis from Work-Bench around the future of enterprise technologies. “Expect all modern BI vendors to release an [automated machine learning] product or buy a startup by [the] end of next year,” the report explained.

This will move down to the rank and file organisations who, ultimately, have to see themselves as a data-centric company going forward. “Organisations need to completely rethink the customer touchpoints and processes to be ready for the convergence of emerging technologies,” says van Rijmenam. “Only those organisations who are capable of seeing themselves as a data company will stand a chance to survive.”

Blockchain: Transforming Your Business and Our World focuses only its last chapter – 14 pages – on convergence. The remaining 180-odd pages explore blockchain’s potential in a variety of scenarios, from poverty, to voting, to climate change. The book describes these throughout as ‘wicked problems.’ Yet the third chapter, on identity, is the ultimate banker.

“We believe that we first and foremost need to solve the identity problem [with blockchain],” says van Rijmenam. “Once we have a self-sovereign identity, it will help make it easier to solve the other issues. That is why we first discussed that problem in our book before discussing the other wicked problems – thus a self-sovereign identity will be the biggest long-term change as it will empower individuals, but also organisations and even connected devices.”

Identity is not the only problem the industry needs to solve before blockchain can make its way truly into the mainstream. While a recent study from Juniper Research found that business leaders’ understanding of the technology is going up solidly, van Rijmenam categorises the issues into three buckets; technological, people, and culture. “Consumers will need to get used to a society where they have to control their own private keys,” he says. “That might be the biggest challenge of them all as it requires a culture shift.”

With this intersection in mind, van Rijmenam is currently working on a new book, focused on ‘the organisation of tomorrow’ and exploring how big data analytics, blockchain and AI will be transformative. “Organisations need to ‘datafy’ their processes, make data available using the cloud, collaborate with industry partners to optimise the supply chain, analyse their data for insights, and automate their business processes using AI,” says van Rijmenam.

Blockchain: Transforming Your Business and Our World is published by Routledge and is available for purchase here.

Main picture credit: https://vanrijmenam.nl/

Multi-cloud initiatives continue to be of great importance to European organisations – and those who aren’t heeding the warning signs today will feel the pinch in five years’ time.

That’s according to a new study from research firm Foresight Factory, alongside application network technology provider F5 Networks. The study, titled ‘The Future of Multi-Cloud’, drew on contributions from Deloitte, CloudSpectator, Ovum and more, having been based on a discussion guide combining publicly available research and Foresight’s proprietary bank of more than 100 trends.

In short – delaying multi-cloud adoption will mean your organisation will become increasingly irrelevant. Yet many organisations will surely be aware of this. Take the study from Virtustream in July, which found the vast majority of organisations (86%) confirming their cloud strategy was a multi-cloud one. Or take how many of the leading cloud vendors are pushing their acquisition and product strategies towards the trend; Cisco acquiring Duo Security, Nutanix buying Netsil, Juniper Networks offering new data centre, campus and branch network offerings.

Everyone is at it. One of the primary drivers for multi-cloud, as the report notes, is fear surrounding vendor lock-in. But the report makes an interesting point: there is a sense of constant change underpinning these initiatives, with the hyperscale vendors more than willing to outspend rivals to keep their market share.

Take machine learning as an example. According to the RightScale 2018 State of the Cloud report, machine learning is the most popular public cloud service with regards to future interest. AWS, Microsoft and Google are all taking big strides in this area, from Google’s pre-packaged AI services, to the various AWS clients citing the technology as key to their success – Major League Baseball, Formula 1, and more. From Microsoft’s perspective, the report notes that its ML focus has led it to invest in new server technologies, with workloads on the edge also contributing.

Yet there are various issues which still need to be overcome. The report cites the well-known skills gap organisations are facing. With multiple cloud services, containers, APIs and more, visibility and management is vital. Plenty of companies have sprung up to help organisations with this – CloudCheckr, CloudHealth Technologies and so on – but ultimately it’s all about service delivery. Consumers may not be interested in the technical intricacies of the multiverse, but they will care if their service becomes inflexible or goes down.

So what can companies do? Their technological landscape is continually changing, driven from the top by initiatives from the largest cloud vendors, and they have more plates spinning than ever. There are a couple of things which can be done, according to the report. Firstly, organisations should focus more on security. Consumers will eventually only be interested in those who have the most watertight systems built in. What’s more, there needs to be an increased focus on nurturing young IT talent – or ‘tapping into the kaleidoscopic potential of youth and promoting industry diversity’, as the report puts it.

In other words, organisations need multi-cloud. With developments in edge computing and artificial intelligence starting to take place driving greater insights and quicker decision making, they need to get on that train as soon as possible. But the skills gap won’t be overcome overnight.

“The multi-cloud ramp-up is one of the ultimate wake-up calls in internal IT to get their act together,” said Eric Marks, VP of cloud consulting at CloudSpectator. “One of the biggest transformative changes is the realisation of what a high performing IT organisation is and how it compares to what they have. Most are finding their IT organisations are sadly underperforming.”

Mission-critical database applications are often the most complex use case in the public cloud for a variety of reasons. They need to keep running 24×7 under all possible failure scenarios. As a result, they require full redundancy, which involves provisioning standby server instances and continuously replicating the data. Configurations that work well in a private cloud may not be possible in the public cloud. And providing high availability can incur considerably higher costs to license more advanced software.

There are, of course, ways to give SQL Server mission-critical high availability and disaster recovery protections on Amazon Web Services. But it is also possible (and all too common) to choose configurations that result in failover provisions failing when needed.

AWS offers two basic choices for running SQL Server applications; a Relational Database Service and the Elastic Compute Cloud. RDS is a managed service that is often suitable for basic applications. While RDS offers a choice of six different database engines, its support for SQL Server requires the more expensive Enterprise Edition to overcome some inherent limitations, such as an inability to detect failovers caused by the application software.

For mission-critical SQL Server applications, the substantially greater capabilities available with EC2 make it the preferred choice when HA and DR are of paramount importance. But EC2 also has a few limitations, especially the lack of shared storage used in traditional HA configurations. And as with RDS, always-on availability groups in the Enterprise Edition might be needed to achieve the desired level of protection.

AWS also offers a choice of running SQL Server on either Windows or Linux. Windows Server Failover Clustering is a powerful and proven capability that is integral to Windows. But because WSFC requires shared storage, the data replication needed for HA/DR protection requires the use of separate commercial or custom-developed software to simulate the sharing of storage across server instances.

For Linux, which lacks a feature like WSFC, the need for additional HA/DR provisions is even greater. Using open source software requires integrating multiple capabilities that, at a minimum, must include data replication, server clustering and heartbeat monitoring with failover/failback provisions. But because getting the full HA stack to work well under all possible failure scenarios can be extraordinarily difficult, only very large organizations have the wherewithal needed to even consider taking on the task.

Failover clustering – purpose-built for the cloud

The growing popularity of private, public and hybrid clouds has been accompanied by increased use of failover clustering solutions designed specifically for a cloud environment. These HA solutions are implemented entirely in software that creates, as their designation implies, a cluster of servers and storage with automatic failover to assure high availability at the application level.

Most of these solutions provide a complete HA/DR solution that includes a combination of real-time block-level data replication, continuous application monitoring and configurable failover/failback recovery policies. Some of the more sophisticated solutions also offer advanced capabilities like support for Always on Failover Clustering in the less expensive Standard Edition of SQL Server for both Windows and Linux, WAN optimisation to maximize multi-region performance, and manual switchover of primary and secondary server assignments to facilitate planned maintenance, including the ability to perform regular backups without disruption to the application.

Although these purpose-built HA/DR solutions are generally storage-agnostic, enabling them to work with shared storage area networks, shared-nothing SANless failover clustering is usually preferred for its ability to eliminate potential single points of failure. Most SANless failover clusters are also application-agnostic, enabling organizations to have a single, universal HA/DR solution. This same capability also affords protection for the entire SQL Server application, including the database, logons, agent jobs, etc., all in an integrated fashion.

The example EC2 configuration in the diagram shows a typical two-node SANless failover cluster that works with either Windows or Linux. The cluster is configured as Virtual Private Cloud with the two SQL Server nodes in different availability zones. The use of synchronous block-level replication across the two availability zones assures both high availability and high performance. The file share witness, which is needed to achieve a quorum, is performed by the domain controller in a separate availability zone. Keeping each server instance of the quorum in a different zone eliminates the possibility of losing more than one vote if any zone goes offline.

Above: SANless failover clustering supports multi-zone and multi-region EC2 configurations with either multiple standby server instances or a single standby server instance, as shown here.

HA and DR configurations involving three or more server instances are also possible with most SANless failover clustering solutions. The server instances can be located entirely within the AWS cloud or in a hybrid cloud. One such three-node configuration is a two-node HA cluster located in an enterprise data center with asynchronous data replication to AWS or another cloud service for DR purposes—or vice versa.

In both two- and three-node clusters, failovers are normally configured to occur automatically, and both failovers and failbacks can be controlled manually (with appropriate authorisation, of course). Three-node clusters can also facilitate planned hardware and software maintenance for all three servers while providing continuous high-availability for the application and its data.

With 44 availability zones spread across 16 geographical regions, the AWS global infrastructure affords tremendous opportunity to maximize availability by configuring SANless failover clusters with multiple, geographically-dispersed redundancies. Such a global footprint also enables SQL Server applications and data to be deployed near end-users to deliver satisfactory performance.

More and more enterprise data is being transferred to the cloud, but sometimes the journey can break the network's back – which calls for less virtual and more physical solutions.

Microsoft has announced the general availability of Azure Data Box, a physical box which organisations can order, fill up, and then return to Redmond for it to be uploaded to an Azure environment. 

Companies and users can store up to 100 TB per standard box, with variables either way. The newly announced Data Box Heavy can handle up to 1 PB of data, while Data Box Disks go up to 40 TB.

For those who may consider this a decidedly low-tech method of cloudy data transfer, it is worth noting Amazon Web Services (AWS) has long since had Snowball, a petabyte-scale data migration tool which carries similar bulk as Azure Data Box. AWS also has the Snowmobile, a 45-foot long shipping container, for data loads up to 100 PB.

The customers who really  benefit from these types of tools are those organisations either with reams of offline data from legacy tools, or those collecting data in hard to access places. For instance, moving an exabyte of data across a 10 gigabit per second line would take the better part of two and a half decades to complete.

Oceaneering International was one of the first customers of Azure Data Box last year. Its underwater vehicles generate 2TB of data per day, with the vessel itself generating up to 10TB per day. "We're trying to get the data to the decision maker quicker," explained Mark Stevens, director of global data solutions, adding it is aiming for a seven day turnaround from the field anywhere in the world.

The other addition to the product family is Azure Data Box Edge, which combines on-premises with AI-enabled edge compute capabilities. With increasing amounts of data being created at the edge, the Edge hardware enables data analysis and filtering at the edge of the network, as well as being a storage gateway.

You can find out more about the Azure Data Box family here.

Picture credit: Microsoft

If you run workloads in Kubernetes, you know how much important data is accessible through the Kubernetes API—from details of deployments to persistent storage configurations to secrets. The Kubernetes community has delivered a number of impactful security features in 2017 and 2018, including Role-Based Access Control (RBAC) for the Kubernetes API.

RBAC is a key security feature that protects your cluster by allowing you to control who can access specific API resources. Because the feature is relatively new, your organization might have configured RBAC in a manner that leaves you unintentionally exposed. To achieve least privilege without leaving unintentional weaknesses, be sure you haven't made any of the following five configuration mistakes.

The most important advice we can give regarding RBAC is: “use it!” Different Kubernetes distributions and platforms have enabled RBAC by default at different times, and newly upgraded older clusters may still not enforce RBAC because the legacy Attribute-Based Access Control (ABAC) controller is still active. If you’re using a cloud provider, this setting is typically visible in the cloud console or using the provider’s command-line tool. For instance, on Google Kubernetes Engine, you can check this setting on all of your clusters using gcloud:

$ gcloud container clusters list –format='table[box](name,legacyAbac.enabled)'
┌───────────┬─────────┐
│ NAME                  │ ENABLED       │
├───────────┼─────────┤
│ with-rbac              │                        │
│ with-abac             │ True                │
└───────────┴─────────┘

Once you know that RBAC is enabled, you’ll want to check that you haven’t made any of the top five configuration mistakes. But first, let’s go over the main concepts in the Kubernetes RBAC system.

Your cluster’s RBAC configuration controls which subjects can execute which verbs on which resource types in which namespaces. For example, a configuration might grant user alice access to view resources of type pod in the namespace external-api. (Resources are also scoped inside of API groups.)

These access privileges are synthesized from definitions of:

• Roles, which define lists of rules. Each rule is a combination of verbs, resource types, and namespace selectors. (A related noun, Cluster Role, can be used to refer to resources that aren’t namespace-specific, such as nodes.)
• Role Bindings, which connect (“bind”) roles to subjects (users, groups, and service accounts). (A related noun, Cluster Role Binding, grants access across all namespaces.)

In Kubernetes 1.9 and later, Cluster Roles can be extended to include new rules using the Aggregated ClusterRoles feature.

This design enables fine-grained access limits, but, as in any powerful system, even knowledgeable and attentive administrators can make mistakes. Our experiences with customers have revealed the following five most common mistakes to look for in your RBAC configuration settings.

Configuration mistake 1: Cluster administrator role granted unnecessarily

The built-in cluster-admin role grants effectively unlimited access to the cluster. During the transition from the legacy ABAC controller to RBAC, some administrators and users may have replicated ABAC’s permissive configuration by granting cluster-admin widely, neglecting the warnings in the relevant documentation. If users or groups are routinely granted cluster-admin, account compromises or mistakes can have dangerously broad effects. Service accounts typically also do not need this type of access. In both cases, a more tailored Role or Cluster Role should be created and granted only to the specific users that need it.

Configuration mistake 2: Improper use of role aggregation

In Kubernetes 1.9 and later,Role Aggregation can be used to simplify privilege grants by allowing new privileges to be combined into existing roles. However, if these aggregations are not carefully reviewed, they can change the intended use of a role; for instance, the system:view role could improperly aggregate rules with verbs other than view, violating the intention that subjects granted system:view can never modify the cluster.

Configuration mistake 3: Duplicated role grant

Role definitions may overlap with each other, giving subjects the same access in more than one way. Administrators sometimes intend for this overlap to happen, but this configuration can make it more difficult to understand which subjects are granted which accesses. And, this situation can make access revocation more difficult if an administrator does not realize that multiple role bindings grant the same privileges.

Configuration mistake 4: Unused role

Roles that are created but not granted to any subject can increase the complexity of RBAC management. Similarly, roles that are granted only to subjects that do not exist (such as service accounts in deleted namespaces or users who have left the organization) can make it difficult to see the configurations that do matter. Removing these unused or inactive roles is typically safe and will focus attention on the active roles.

Configuration mistake 5: Grant of missing roles

Role bindings can reference roles that do not exist. If the same role name is reused for a different purpose in the future, these inactive role bindings can suddenly and unexpectedly grant privileges to subjects other than the ones the new role creator intends.

Summary

Kubernetes RBAC configuration is a critical control for the security of your containerized workloads. Properly configuring your cluster RBAC roles and bindings helps minimize the impact of application compromises, user account takeovers, application bugs, or simple human mistakes.

Check your clusters today—have you made any of these configuration mistakes?

Many business leaders have a much better understanding of blockchain technology than just a couple of years ago. There's been a surge in R&D, both internally and in partnership with third parties, and a recognition that blockchain has the potential to be deployed in a variety of commercial use cases.

As the number of blockchain research projects increased, awareness among the pilot participants and elsewhere in their industries gained momentum. Now other companies are beginning to consider whether they, too, should seek to gain a competitive advantage from a proof-of-concept deployment.

Blockchain market development

According to the latest worldwide market study by Juniper Research, 65 percent of survey respondent enterprises with over 10,000 employees are considering or actively engaged in blockchain deployment. This marks a significant rise from 2017 when the corresponding figure was 54 percent.

Moreover, nearly a quarter of companies considering deploying blockchain had moved beyond proof-of-concept into trials and commercial rollouts, with dramatic diversification in use cases over the past year.

Only 15 percent of proposed deployments were now related to payments – compared with 34 percent last year – with significant interest in opportunities across diverse fields including logistics, authentication and smart contracts.

The study findings also identified savings and cost reductions across a range of verticals in areas such as compliance and fraud reduction, including a forecast of more than $100 billion by 2030 in food exports.

The survey results revealed that nearly half of companies were considering using Ethereum as their blockchain; reflecting the fact that its token standardization has enabled the creation of an ecosystem of distributed applications (dApps) to be built on its chain.

Furthermore, all the responding companies which had already invested over $100,000 in blockchain indicated they would be spending at least this amount again on the technology over the next 12 months.

According to the Juniper assessment, this demonstrated initial C-suite feedback had been largely positive in most cases, sufficiently so for executives deciding to move to the next stage of integration. That said, three-quarters of respondents expect some disruption to internal or external systems.

Outlook for blockchain applications

"The findings illustrate the need for companies to engage in a prolonged period of parallel running new systems alongside the old, to resolve any issues that might arise," said James Moar, senior analyst at Juniper Research. Regardless, we should anticipate more blockchain application development in the future.

The survey participants also acknowledged IBM as the leading vendor for blockchain project planning and deployment, with the tech giant ranked first by 65 percent of respondents — that's nearly 10 times more than the second-place vendor, Microsoft (7 percent).

Software as a service (SaaS) is becoming ubiquitous. It is estimated that enterprises currently use 16 SaaS applications on average, yet one in seven of these businesses also believe that more than 80% of their applications will be SaaS-based by 2020.

This would seem an especially accurate assessment too by enterprises, as the current market for SaaS products and services is worth £54 billion, yet it is expected to jump to over £85 billion by 2021.

Based on this upward trajectory, SaaS application providers clearly have a huge opportunity on offer. However, how can they maximise it? 

As ThousandEyes works with some of the top SaaS providers around the world, we’ve gleaned five key, operational ‘habits’ for successful delivery. Importantly, it is key to realise that successful delivery doesn’t just focus on your own company’s culture, or strategic direction, or even your operational knowledge. It also encompasses relationships with customers, vendors and other third-party providers.

Don’t point the finger so quickly

Every SaaS provider knows they will face up to both application and network issues, regardless of how good their product is. However, when it comes to actually solving these performance issues, the network tends to be singled out for blame first. This means your network team needs to prove its innocence before your application team will deal with the problem. With this type of culture, it can be a huge distraction from dealing with the issue at hand, while also stunting team collaboration, which will help with resolving issues quicker. Getting your teams to provide a quick view of network health, with application context, can define where the issue lies and be a huge help in dealing with problems.

Relationship with third-parties need to change

A simple fact for the vast majority of service providers is they can’t investigate, or even acknowledge, all performance-related inquiries they receive on a daily basis, due to finite resources. This situation can make resolving issues quite a challenge for you, as a SaaS provider, particularly if there’s no actual data to work off to show a fault.

A natural byproduct of this is that you can fall into a quite unproductive routine of trying to escalate problems, yet your service provider prefers to deny, deflect and defer.

Most of your third party providers will not spend their time troubleshooting for you, particularly if they are responsible on fixing an issue, or, especially if they may face a service level agreement (SLA) penalty.

Evidence in this scenario is critical. Forget mantras like ‘find and fix’, instead you need to adopt an ‘evidence and escalate’ approach. This involves having a proven set of steps to collate evidence, regardless of if you do not control certain services or networks, in order to successfully escalate an issue. 

With this approach, you are no longer relying solely on your external providers. Instead, you’ve taken control of the process and the benefits are significant, including reducing the time it takes to resolve problems, while also having the knock-on effect of benefiting the user’s overall digital experience.

Deal with customers in the right way

Every day, SaaS providers maintain an illusion. They provide a seamlessly delivered application, yet behind the curtain, they work extremely hard to build a unified customer experience, despite many different complex components and reliance on third parties. It is a very hard balancing act for providers. They can’t afford a questionable Internet service provider (ISP), a compromised domain name system (DNS) cache, or false route advertisements, or broken API endpoints.

However, when something goes wrong, as a provider, it is essential that you can speedily attribute responsibility to the right part of the user experience. This is not just to resolve the issue itself, but also so you can communicate with users quickly and effectively, which is crucially important as today’s end users demand a huge level of transparency. 

In order to do this, active networking monitoring is the solution. This technology can provide an unrivalled, clear view of the application delivery path from your customers, all the way to your application servers. This provides a precise understanding of where and why something isn’t working and also enable you to update your customers in a transparent and insightful way.

Monitor interservice communication that includes external networks

The majority of SaaS providers are relying on external APIs for their user experience now. This ranges from things like payment gateways and customer relationship management (CRM) databases. Yet anytime an external API is used, it becomes part of the application stack and, thus, needs to be managed. Again, you need to keep a close eye on when and why your APIs are available and performing (or not), to deal with any issues impacting on the user experience.

The lifecycle can’t end when monitoring your service

Sometimes monitoring can be treated as just an operations practice, in order to ensure service uptime. Yet, this is short-sighted as having access to data early in the application journey can be really useful for enabling you to make better choices around application architecture and network. 

For example, your choice of the location of data centres or workloads in public cloud providers can have a significant impact on service delivery. Therefore, with issues like this, you need to have detailed, visual, and reportable data that charts every aspect of user experience from web server, to network path, to Internet routing. This information is like gold dust before rolling out a new service, enabling you to remove (as much as possible) the risk from your most important SaaS planning decisions.

One thing to keep in mind about these five habits is that they rely on end-to-end visibility, which can be provided by leading network monitoring solutions. This enables a huge degree of transparency in performance across not just your own application, but also your providers. With visibility at the heart of your approach you can really change, for the better, how you deliver your SaaS application, while also future-proofing your performance to make sure you maximise the huge opportunity that is developing in the market.