(c)iStock.com/BrianAJackson

Even in mid-2016, very few who are serious about cloud computing will tell customers that out of the box public cloud services are as secure as their corporate data centres. At the same time no-one would suggest introducing mission critical applications and data into a brand new data centre environment without first planning and implementing proper physical, network, server, and application security controls.

Many organisations distrust moving corporate data and application assets into the public cloud. Loss of control of these assets is the most common reason stated; this is code for loss of control over the security aspects of the environment. To answer this, public cloud providers have developed some form of Shared Security Responsibility model.

For example, Amazon Web Services states that they are responsible for security of the physical plant as well as the separation between accounts or instances, while customers are responsible for building security into the solutions they deploy into their cloud account or instance. In other words, AWS is responsible for the security “of” the cloud and the customer is responsible for security “in” the cloud.

An often used solution that many organisations undertake in the separation of front end or presentation layers and the data aspects of a service into a hybrid cloud. This does not preclude any security deployment best practices that we will speak about but provides a level of comfort for organisations that their data is under their lock-and-key.  While hybrid cloud does not provide as much costreduction, flexibility or elasticity as “going public”, it does help the customer organisation feel more secure, in their decision.

Given the customer’s responsibility of security “in” the cloud, the customer needs to approach security around public cloud hosted instances in a similar (if not the same) manner that they approach corporate data centre hosted applications. Virtualised software components are available for everything from firewalls, to identity management, to intrusion detection, to virus checking, and many other aspects of the security landscape. If you wouldn’t deploy an application into your corporate data centre without a perimeter firewall, why would you deploy it into a cloud environment without the same technology?

When choosing a public cloud provider, it is prudent to look into the provider’s track record when it comes to security incidents. Again the provider is responsible for security “of” the cloud, so knocking a provider for a customer’s lack of proper security controls would be unfair. Most if not all public cloud providers publish data on their ability to protect their data centres and the overall cloud provisioning environment. So, do your homework.

Another aspect of the provider’s environment that may be useful in making an appropriate choice is evaluating the tools that the provider deploys to help a customer secure the environment. Once again using AWS as the example, they provide a list of security focused tools including:

• WAF: AWS WAF is a web application firewall that helps protect your web applications from common web exploits. WAF controls which traffic to allow or block to web applications by defining customisable web security rules.
• Security groups: A security group acts as a virtual firewall that controls the traffic for one or more instances. When an instance is launched it is associated with one or more security groups. Rules are added to each security group that allow traffic to or from its associated instances.
• Network access control lists (ACLs) – A network access control list (ACL) is an optional layer of security for your virtual private cloud (VPC) that acts as a firewall for controlling traffic in and out of one or more subnets.
• Virtual private gateway (VPG) – By default, instances launched into a virtual private cloud (VPC) can’t communicate with an external network. You can enable access to an external network from a VPC by attaching a virtual private gateway to the VPC, creating a custom route table, and updating your security group rules. IPSEC tunneling and connection to a Hardware VPN are supported.
• Inspector: An automated security assessment service that helps improve the security and compliance of applications.
• Identity and access management (IAM): Role based identity and access management for AWS account and logins.

Microsoft Azure provides many similar features to assist in securing environments in the cloud. One interesting option available from Microsoft is Azure Stack. Azure Stack is a hybrid cloud platform that allows an organisation to host a functional Azure deployment on premise, in their own corporate data centre. Not only can the on-premise environment be setup to interact (as expected) with Azure online resources, it is also managed from the same management console as the online environments.

Finally, when speaking of hybrid cloud environments, the customer has to prepare the corporate data centre environment properly with sufficient rigour to ensure security on their end. The corporate side of the VPN needs to be secured with the appropriate tools (Firewalls, IDS) and monitored as any other corporate environment.

Many organisations are struggling to balance the benefits of public cloud (lower costs, elasticity, scalability and flexibility) with concerns about security. While public cloud still does not provide the comfort level of hosting applications in the corporate data centre, it is evolving as an attractive option even for those who need a higher level of security. Hybrid cloud is one possible way to balance these needs if an organisation views the public cloud as an extension of the corporate data centre while planning for and implementing security “in” the cloud as if it were another data centre that they have access to.

(c)iStock.com/Courtney Keating

Don’t take this the wrong way. As anyone who has been reading my articles can tell, I am all about the technology that enables DevOps but sometimes the greatest change in the enterprise comes from non-technical places.

To many of you reading this statement, that might be a radical concept – but when it comes to overarching changes such as implementing a DevOps program, culture is much more important than what code repository to use. DevOps in particular not only relies on changes in the technical environment, even more so in how people work together, interact and develop.

The DevOps Enterprise Summit (DOES) attracts development, operations, and business leaders from companies small and large looking for information on implementing DevOps and fundamentally changing their business. A theme which runs through every keynote speech is “you need to change the culture of your enterprise while changing the technology.” Every DOES speaker that I have heard stresses this message and discusses the cultural challenges that they have gone through.

There are three main areas of cultural change which can enable implementation of DevOps:

Teamwork and communications

First and foremost, a one-team attitude must be adopted. This applies to people from application development, infrastructure development, architecture, operations organisations, or business stakeholders. No matter the person’s specific job, satisfying the enterprise goals are everyone’s job. Equally, never say ‘it’s not my job’; although everyone comes to a project with their particular expertise, it is the team’s responsibility to successfully reach the enterprise goals.

Keep your partners close. Partners bring their own unique expertise and capabilities to the enterprise. Involving them in projects early and keeping them involved throughout will provide a new perspective. Make life challenging and exciting; engage those people who have passion and are excited by the prospect of doing something new, then challenge them to go beyond what has already been accomplished.

Leadership also needs to foster a culture where communications is critical. No skunk works allowed here; everyone on the team is kept up to date on progress and – if needs be – setbacks.

Leadership and sponsorship

Leadership’s first job is to identify roadblocks and eliminate them. Whether these roadblocks are process based – the three weeks it takes to get purchasing to read the purchase order you sent – or communication based – ‘oh, you sent me an email last week?’ – leadership must work to reduce and, or, eliminate the bottlenecks that are so prevalent in today’s IT world. To use networking terms, it is not just fostering communication within the team in an east-west manner, but also north-south between leadership and the team, executive management and the rest of the enterprise.

In the traditional model, without executive sponsorship and especially in large organisations, a major rollout will be slowed. When it comes to DevOps, executive sponsorship can be helpful in terms of funding and communicating to the rest of the organisation, but growing the effort at the grass roots level is how DevOps implementations expand. When a DevOps team member sits down to lunch with his or her friend from another development group and talks about how great things are going…well, you get the picture.

Starting up and growing

One team buying in doesn’t guarantee growth, but you have to start somewhere. DevOps in every instance that I have heard of started with one development group and the operations staff that supported them. No grand, big bang implementation of DevOps can work because it requires people of all types to buy in and get used to doing things differently.

Engineers, developers, operation support, techies of all types like to innovate. Technologists see value in doing something new that benefits them and their organisation. A representative of banking firm Capital One, when speaking about the value of DevOps to their engineering staff, was recently quoted as saying “the intrinsic value for engineers is so high, they’ll even willingly deal with lawyers.”

Crucially, DevOps should be fun. Schedule events to get other people involved – not stodgy speeches, but interactive events. Target senior group managers Heather Mickman and Ross Clanton have spoken twice at DOES and have stressed the importance of what they call “DevOps days” – events in growing awareness and interest in joining the wave of DevOps at Target.

Conclusion

Ultimately there are a number of key technologies and methodologies that need to be brought to bear in order to enable DevOps in the enterprise. But while we are implementing cloud environments, common code repositories, agile development practices and infrastructure as code, we need to keep in mind that the cultural aspects of DevOps implementation are just as important, if not more so.

(c)iStock.com/franckreporter

The DevOps Enterprise Summit last month had a record number of attendees and speakers, all of whom were there to discuss the tremendous positive impact DevOps is having within the enterprise.

When representatives of financial services companies (not the usual industry of early adoption) such as ING, CapitalOne and Bank of America are listed among the speakers, it’s time to pay attention. This and the preponderance of articles presenting evidence, that enterprises of all kinds and sizes, are showing tremendous gains through the implementation of DevOps practices has to get the rest of the technical community thinking.

Let’s face it: which CEO wouldn’t want to see their development and operations teams and their business working seamlessly to define, deploy and maintain services for customers? Which CFO doesn’t want to hear that maintenance of services costs are down significantly?

As I recently wrote in Stop talking about cloud – and start talking about what cloud can enable: “DevOps is more than just a shift in how operations, development and the business stakeholders technically work together to develop new services. It is a cultural shift within an enterprise, which changes how business and technology relates to each other.

“This cultural shift causes technology organizations to move at a different pace than previously – a pace which can keep up with the business demands of time to market, as well as product and services lifecycles.”

So for those of us who could use a refresher into DevOps, I offer the following quick overview on DevOps components and benefits. There are many ways to implement DevOps and many components to choose from, not all listed below.

As with any methodology, an enterprise should choose those components that are appropriate to their situation. As this is only an overview, I remind the reader that a good deal more research needs to be done before trying to implement any of these components.

Community and culture

All the technology and tool changes in the world cannot replace the need to fundamentally change how the parts of a business (technology, architecture, engineering, application development, sales, marketing, product development) work together.

That may be a bold statement, but ask anyone who has successfully implemented a DevOps program. Without the following cultural mindset your impact will be limited:

• The various organisations need to see themselves as one team heading in the same direction.
• Process is critical and it needs to be a custom fit for the enterprise.
• Leadership is responsible to remove process roadblocks, not just reduce them. Anything that slows the teams down without a serious business reason needs to be looked at.
• All team members need to see themselves as a key part of the team. Get rid of the “it’s not my job” mentality.
• Start small and expand the community over time.

Application and infrastructure development

There are specific parts of DevOps that are development specific, but the all other teams need to understand what the development teams are doing and how they need to be supported. When I speak about development I am including a team that is creating components of the solution, application, API, tools, or infrastructure.

• Employing an agile methodology that fits your enterprise (and is common across the enterprise) is the first big step.
• Deployments need to be small and focused. This will allow for quick identification and repair of bugs as well as enable rapid/continuous deployment of new features and functions. This is one point where the rubber-meets-the-road in terms of rapid reaction to changing markets and business requests.
• As part of the deployment process, testing needs to be well defined, highly focused and rapidly executed. This may be one of the most difficult parts of the DevOps process to implement but also has the biggest impact.
• All application development should be based on APIs and software as a service (SaaS) concepts. Code and configuration repositories, Source code and configuration versioning and controls,  API and service based access to functionality. These provide flexibility and compartmentalisation necessary for continuous and rapid deployment.
• Infrastructure as code (IAC) is becoming a very big component of DevOps. In short IAC is the use of code development practices in the development and deployment of infrastructure configurations.

Operations and orchestration

To clarify: operations are not that group down the hall that we toss applications to! DevOps, as the name implies, requires that development and operations are partners in the creation, deployment and management of services.

Operations, as well as business stakeholders, need to be involved in the development process from the beginning. This will allow for the definition of supportability, testing, management, and security aspects of the services.

• Much the same as developing code around APIs, operations components should be developed as building blocks. This will, once again, increase flexibility, supportability and rapid issue resolution.
• A great concept that I recently heard about is the use of Flash Build Sessions to include partners and energise teams as part of the infrastructure and operations development process.
• While the choice of platform is a enterprise wide responsibility and needs to be considered seriously by all involved, a hybrid cloud platform is the platform of choice for agile enterprises. Hybrid cloud allows for rapid deployment of new services, issue resolution changes and upgrades.
• A standard set of orchestration tools coupled with hybrid cloud allow all involved to work more efficiently and more collaboratively.

Supporting concepts

There are a number of general supporting concepts that help enable a DevOps collaborative environment within the enterprise. Some of the top areas to keep in mind are:

• Consistent and continuous communication between teams and within teams is critical. Chat, Instant Messaging, Social networking, and/or email, whatever works for the enterprise.
• Leadership. DevOps cannot exist without strong leaders. Leaders are those who are willing to lead efforts by example and not by managing.
• Strong External Technology partnerships. Keeping your partners close will keep projects moving. They have knowledge about their components that you need and they are willing to share.

In conclusion, enterprises of all sizes and shapes are moving towards DevOps models. Many of the models differ greatly from each other, even within the same industries. The best way to get started is to choose a small team, a few things to change and one project to try this out on. There will be bumps in the road but keep trying and the benefits will show up eventually.

(c)iStock.com/Clint Spencer

Cloud computing is still a very trendy topic of discussion among technology leaders around the world. It’s easy to see why; cloud adoption rates are on the rise and are predicted to continue their upward trend, while cloud service providers (CSPs) continue to roll out new features, products, and services.

Times are good in the world of cloud computing – but I believe the conversation has begun to change and is about to change to a greater extent.

Cloud, as we all know, is a platform option and not an end onto itself. As technology professionals have always known, a platform is only as effective as what it can be used for. In recent conversations with customers and colleagues, I have attempted to steer the conversation – trying to be a good enterprise architect – more towards what an enterprise can use cloud for, as opposed to the “I need to be running on cloud because the CIO wants it” discussion.

There are any number of excellent examples of enabled technologies and processes that cloud can and should be the basis for, and this is where the conversation and the focus needs to gradually move to.

DevOps

DevOps is more than just a shift in how operations, development and the business stakeholders technically work together to develop new services. It is a cultural shift within an enterprise, which changes how business and technology relates to each other.

This cultural shift causes technology organisations to move at a different pace than previously – a pace which can keep up with the business demands of time to market, as well as product and services lifecycles.

At the heart of this new pace is cloud’s ability to rapidly provision and change development and test environments. Cloud’s ability to create and change hybrid environments also allows for additional flexibility and more effective costing for development, test, deployment, update, and retirement of services.

Internet of Things

The Internet of Things (IoT) and the technologies that support it are rapidly growing in use and importance in the technology and business world.

The diversity of industries looking at IoT is on the rise. Even financial services firms are looking at IoT as a possible competitive edge in the marketplace. The simplest way to describe IoT conceptually is the transmission, collection, aggregation, analysis and reaction to, large number of small size sensor or device data.

This requires considerable and ever changing compute resources to handle this data as various stages of the process. The flexibility of cloud and the ability of a hybrid cloud to easily put resources ‘close to the action’ make it an excellent choice for an IoT platform.

Geographic distribution of services

Many times, customers have asked how they can cost effectively distribute services across a geographically diverse enterprise. These enterprises are no longer willing, and in many cases able, to put together a business case for standing up replicated server installations at multiple points on the globe.

Enter the hybrid cloud. In a multi-region hybrid cloud environment, the regions that live in the public cloud space can be geographically located close to business centres to enable users to utilise services from the region closest to them. This provides a geographic distribution of services at a much lower cost, and also enables the rapid deployment of a new site, change in resources in a region, or retirement of a site as user and business patterns change.

High availability (HA) and disaster recovery (DR)

Similar to geographic distribution, enterprises are tired of having to stand up a secondary set of hardware to be used only sparingly until a HA or DR event occurs. Today’s business environment simply won’t tolerate it.

Recent introductions, or upgrades, by many CSPs and cloud platform vendors have been focused on solving this problem, in the cloud. For example, Microsoft’s Automated System Recovery (ASR) product has gone through a major update with the focus being the provisioning of a passive DR environment in the Azure Cloud. The on-prem or in-cloud environment is replicated in a separate Azure cloud space. The virtual machines are then inactivated except for two, which remain up to monitor the primary site and maintain storage integrity. When an event is recognised by the monitoring VMs, the secondary site is activated and services restarted in the cloud.

Conclusion

These are just a very few cloud enabled technologies; many more exist and more than that have yet to be discovered. We as technology leaders need to shift the conversation within the enterprises we support back to what the future state looks like based on business need, and utilise cloud as a platform option to attain that future state.

(c)iStock.com/cherezoff

The problem

One of the basic tenets of cloud computing is the ability to provide access to resources across a geographically dispersed cloud environment. This makes the cloud ideal for global distribution of applications and data. But what about those geographies that have highly restrictive data sovereignty laws or practices, such as Germany, Austria and South Korea? What about governmental bodies attempting to protect information while utilising the cloud?

An interesting example is the German government which, in certain circumstances, will require that data on German companies and their employees never leave German soil and that only German citizens be allowed to administer said data. These data sovereignty (DS) scenarios and many others present a challenge for organizations in terms of protecting the data entrusted to them while cutting costs and gaining efficiencies associated with the cloud.

From a business standpoint, these organisations are charged with protecting information about their business, customers, users or governments. Unauthorised access to private customer data, governmental assets or corporate assets could be devastating. We need look no further than the recent state sponsored attack on US federal government employee databases to see the effect of these types of breaches.

From a technical view, IT departments are being increasingly relied upon to implement data access controls, data filtering and separation management functions according to DS rules. Then as soon as IT thinks they finally have a handle on the problem, here comes the cloud, offering ubiquitous data access, and messing up the nice neat model they’ve created.

So, how do we control data where the point of cloud is to distribute data and applications? Large organisations, especially those that span multiple countries are facing this very question on a daily basis. I was recently involved with a client that not only does business globally and needs to be sensitive to governmental restrictions, but also has specific contractual obligations with a number of their customers as to where and how files, email and other data can be stored and transmitted.

The solution

The chosen solution will be specific to the circumstances and organisational type, although it can be viewed as having various components:

• Security standards. These solutions require a strong set of on-premise and cloud based security standards. As I have previously written, it is important when developing a hybrid cloud solution to extend the corporate security standards, as much as possible, to the cloud.
• Data loss prevention (DLP) monitoring and controls. DLP software defines controls over the flow of data and monitors that data flow to detect data breaches.
• Data aware services. As services are developed, the integrated software components need to have proper authorisation and filtering capabilities. An example would be an identity management system where the directory services replicate data between geographically dispersed instances, based on filtering rules.
• Data segmentation across a hybrid cloud infrastructure. As in the example given above, countries or organisations may require different levels of DS control necessitating that data have a defined location. In this case, a straightforward solution comes in the form of hybrid cloud with regional instances located at or in proximity to the point of high DS requirement.
• Consistent management tools. Common and consistent management tools and practices across all cloud regions with controls in place as to who is authorised to administer a given instance, or data set.

The following diagram shows an example solution utilising all of the above concepts.

IT teams facing data sovereignty and data protection issues should not view the cloud as a challenge to be overcome, but as a partner to be embraced. The technology and best practices exist to gain all the benefits of cloud computing while ensuring the protection, privacy and authorised access to sensitive and regulated data.

(c)iStock.com/4x-image

Analysis If we think about the basic functionality that we take advantage of in the cloud, a whole set of possibilities open up for how we plan for disaster recovery (DR).

Until recently, disaster recovery was an expensive, process intensive service, reserved for only the most critical of corporate services. In most cases DR has been about large servers in two geographically distributed location and large data sets being replicated on a timed basis. Many smaller or less critical services were relegated to a backup and restore DR solution although in many cases as these applications “grew up”, organisations realised that they too needed better protection. Unfortunately, the cost of standing up a legacy style DR environment remained prohibitive for all but the largest and most critical services.

As the world has moved to virtual data centre (VDC) and cloud based services we have seen the paradigm shift. Many features of private, public and hybrid clouds provide a solid basis for developing and deploying highly resilient applications and services. Here are some of the features that make this possible.

• Lower infrastructure cost. Deployment of services into a cloud environment has been shown to be highly effective in reducing acquisition, upgrade and retirement costs. While an organisation’s “mileage may vary”, planning and choice of appropriate cloud options can provide an environment to protect a much larger range of services.
• Regionalisation. The ability to create a cloud environment based on multiple geographically distinct cloud infrastructure instances. This allows the “cloud” to operate as one while distributing load and risk to multiple infrastructures. These regions can be built in a number of ways to fit the organisation’s requirements.
• Storage virtualisation and cloud based replication. The biggest issue facing any DR solution hasn’t changed just because we live in the cloud; data consistency is and will remain the number one headache for DR planners whether utilising legacy technologies or the cloud.

  Fortunately, over time the maturity of storage virtualisation and cloud based replication technologies has increased in an attempt to keep up with the challenge. Once again, organisations need to understand their options in terms of hypervisor based replication, such as Zerto, which replicates data on a hypervisor-by-hypervisor basis, or storage based virtualisation, such as VPlex and ViPR from EMC, for storage based replication.

The key concept in DR planning in the cloud is the creation of an extended logical cloud regardless of the physical location. Let us look at three possible solutions utilising varying cloud deployment models.

Multi-region private cloud

In this option, both the primary and secondary sites, as well as the DevOps and management environments sit within the organisation’s internal environment. The primary and secondary are configured as regions within the organisation’s private cloud.

The biggest benefits to this option are that data is replicated as wide-area-network speed and corporate security policies can remain unmodified. The downside to this option is the need to acquire multiple sets of infrastructure to support the services.

Multi-region hybrid cloud

In this option the services are developed, managed and primarily deployed to an in-house private cloud environment while the secondary site resides within a public cloud provider’s domain. This configuration reduces the need to purchase a secondary set of hardware but also increase data replication load over the public Internet and the time required to move data to the public cloud. 

Multi-region public cloud

In this option both primary and secondary sites reside in the public cloud and depend on the cloud provider’s internal networking and data network services. The service’s management and DevOps still reside within the organisation. This is the lowest cost and most rapid growth option due to low acquisition and update costs as well as providing the most flexibility. The possible downsides to this option are data movement to and from the cloud, and the possible need for adjustment to the organisation’s security policies and procedures.

The takeaway

Many aspects of the above solutions need to be considered before beginning a project to use the cloud as a DR target.

There are plenty of items to think about – not least your disaster recovery operations mode, and whether it is active/active or active/passive. Just like legacy DR solutions, a decision needs to be made about the activity or non-activity of the DR resources versus the cost or benefit of utilising, or leaving idle, a set of resources. If it is a benefit to reach a wider geographic region, then active/active might be a consideration, although keep in mind that active/active will require two-way replication of data, while active/passive will not require this level of coordination. Networking is also key; DNS, user access and management connectivity to the environment needs to be thoroughly planned out.

The biggest concern I have heard from customers is, “How do I enforce the same security standards on a public cloud environment as I have for my in-house environments?” This is an excellent question and one not answered lightly.

In many cases corporate security policies (including perimeter controls, IDAM, logging) can be translated to the public cloud by being a little flexible and a good deal innovative. For example, virtual perimeter firewalls can be implemented, and controlled from the same SOC as their physical counterparts. Also, the same IDAM system that is utilised in-house can modified and then accessed over the net in a public cloud based environment.

Keeping the applications that make up the service in sync across regions requires that when updates are made to the primary virtual machines, virtual machines in the secondary environments are also updated. The implementation of a cloud orchestration tool, such as CSC’s Agility suite, can help a great deal.

One decision point that an organisation needs to come to is between virtualisation of data and replication of data. This carefully considered decision depends on the chosen DR operations mode and the application architecture. Another viable option is for the application to maintain the consistency of the data. The best example of this is directory services (below). Directory services applications are built to maintain data consistency across the multiple controller groups.

It is still true that moving large amounts of data in the public cloud can be a slow and painful process. Unfortunately, most applications will need to have sizeable data sets deployed as some point. I have advised a number of customers to limit the number of large data moves to major version deployments and changes to the underlying structure.

Even if the number of large data moves is limited, proper data architecture and structure is critical. Data consistency based on the DR mode and data replication strategy – in other words, how soon the service needs to have data consistent across regions – is another aspect that needs to be understood.

The following is a high level diagram that shows a hybrid solution for directory services:

The easy part of this solution is that the domain controllers are built by the software provider to stay synchronised. This reduces the data replication problem to providing a large enough network connection for the transactions.

Fortunately, the “add, change and delete” transactions typical of directory services are very small and even in a high volume environment do not need a very large pipe between private and public clouds. Also, while a physical firewall controls access to the primary private cloud environment, an equivalent virtual firewall is used in the public cloud.

OpenStack has become a force to be reckoned with in the cloud computing market. The 451 Research Group forecasts OpenStack related sales at $3.3 billion (£2.13bn) by 2018 – pretty good for an open source development project.  But is it truly ready for the big time?

A potted history

OpenStack was introduced in 2010 as a project of NASA, who dropped out in 2013, and Rackspace. In 2011 Ubuntu adopted OpenStack and became the first “vendor” to integrate with the platform. In 2012 Red Hat began a project to integrate with OpenStack and introduced commercial support by July 2013. Over time many other organisations have joined the foundation as sponsors and contributors. Recently released OpenStack Kilo (version 11) has approximately 400 new features and was the product of almost 1500 contributors.

There is a downside to the open source model: lots of developers with lots of ideas about what should be included breeds complexity

The intent of the project was to create an open source cloud platform that enabled organisations to build their own cloud environments and have them communicate with other open cloud environments. The intended benefits of the OpenStack project were:

• An open source style support model where developers all over the world were ready to help.
• A essentially free open source pricing model.
• Seamless workload migration between OpenStack clouds, without worrying about the underlying virtualisation technologies. This was intended to give rise to a true hybrid cloud paradigm.
• Do-it-yourself cloud environment setup, creation and management

As time went on and the OpenStack foundation grew, projects were added and the core began to take shape. An every six month release cycle was put in place and OpenStack seemed headed for greatness. But there is a downside to the open source model: lots of developers with lots of ideas about what should be included breeds complexity.

A sprawling ecosystem

Over time, what started out as a platform for creating cloud compute, network and storage instances has evolved projects and components to cover many ancillary items.

The core components generally available in OpenStack are:

• Nova – cloud computing fabric controller
• Glance – provides discovery, registration, and delivery services for disk and server images
• Swift – a scalable redundant object and file storage system
• Horizon – graphical interface dashboard services. Third party products compatible
• Keystone – centralised directory based identity services
• Neutron (formerly Quantum) – system for managing networks and IP addresses
• Cinder – block storage services. Includes support for Ceph, Cloudbyte, EMC, IBM, NetApp, 3PAR and many others
• Heat – Orchestration services for multiple could components utilising templates
• Ceilometer – Telemetry Service provides a single point of contact for billing systems

Example components that have been added or are in the works are:

• Trove – database as a service provisioning
• Sahara – Elastic Map Reduce service
• Ironic – bare metal Provisioning
• Zaqar – multi-tenant cloud messaging
• Manila – shared file system
• Designate – DNS as a service
• Barbican – security API

Once the core components were developed by the OpenStack foundation, the ancillary projects were layered into the infrastructure. These are all great ideas, but all contributing to a larger and more complex stack. This complexity shows itself mostly in the configuration and deployment of the infrastructure.

A typical OpenStack deployment looks approximately like the following:

The above diagram is highly simplified and based on the VMware Integration with OpenStack (VIO) product. Note the inclusion of the VMware Services Processor (VSP) virtual machine.

All of the components of an OpenStack infrastructure are deployed as virtual machines whose numbers can be increased or decreased easily according to demand. If a multi-segment cloud is necessary (for example geographically distributed) multiple replicas of the above can be created and associated as regions within the same cloud. Even with the use of a vendor integrated OpenStack product (as above), deploying an infrastructure of this type requires considerable planning, integration and configuration of the various components.

Another aspect that arises from the complexity of the deployment is that increasingly organisations will turn to a vendor for help in deploying OpenStack. A not totally unforeseen consequence is that many vendors have developed their own integrated versions of OpenStack – this is where that big number at the beginning of the article comes from.

The best practice is to roll out core services, and then only add the ancillary services that are necessary

Some of the vendors who market OpenStack integrations are VMware, Red Hat, IBM, HP, Cisco, Ubuntu and F5. Even my own company (CSC) when developing their hyper-converged private cloud offering set, chose to use integrated versions, from VMware and Red Hat, for two of the three offerings.

So, is OpenStack ready for prime time? I believe with the right planning, and the support of an integrated vendor, yes, OpenStack is a viable paradigm for creation of private and hybrid cloud environments. Let us look at the original list of intended benefits:

• Open source support model – still holds true but you can (and should) add on vendor support to better protect your investment of time and money
• Open source pricing model – vendor-integrated OpenStack solutions are still considerably less expensive than the vendor’s non-open Source solutions.
• Seamless workload migration – If configured properly all of the benefits of workload migration can be realised.
• DIY cloud – This requires either staff that are well trained in OpenStack deployment or help from a vendor. Once your staff is trained and has lived through a deployment or two (in the lab) it is all DIY from there. Our staff at CSC, having worked with both vendors is now capable of delivering a private cloud environment to a customer in a matter of days.

On the issue of complexity, a great deal of attention has been paid to the seamless integration of the core components, in recent OpenStack releases.

At its heart OpenStack is a pluggable, modular architecture where new components can be spun up easily. The best practice here is to roll out the core services and then only add the ancillary services that are necessary.

(c)iStock.com/loops7

Can VMware’s NSX finally fulfil the promise of SDN?

The first time I heard the acronym SDN was more than 10 years ago. At that time SDN was the cool way of saying “once the networking guys have racked, stacked and wired the switching and routing components we can install tools on a server and configure them through those tools from the comfort of the NOC”.

This was much more than just standard monitoring and management; we could setup whole networks and change them around, in software. But alas, this wasn’t really what we were hoping for and we would have to wait a number of years for the next advance.

The next evolutionary step was realized when VMware came out with the ability to create a virtual switch on top on their ESX hypervisor (Virtual Distributed Switching or VDS). Now we were talking slick. The ability to hang a switch without having to roll out physical hardware – amazing! Just provide some basic networking hardware at the perimeter, enough CPU to support your networking needs and start building networks. Great, but not quite good enough. Some of the questions left unanswered were:

• Modern networks consist of much more than basic switches and routers: what happened to the other components?
• How do I as a provider of cloud services keep the multiple tenant networks from affecting each other?
• How can I provide overlay networking capabilities to decouple the logical networking world from the physical?

In other words: “You promised me real virtual networking, so where is it?”

NSX-v

Enter VMware’s NSX for vSphere (NSX-v). Does it do everything? No, but it gets the cloud world a whole lot closer to the promise of SDN. The following picture provides an overview of the functions that VMware NSX-v provides:

The Virtual Distributed Switch (VDS) is the basic building block for the overall NSX-v architecture. VDS, as previously mentioned, is the original SDN function but in NSX-v the VDS has taken on a much more complete set of switching capabilities, including multi-layer switching.

Routing within NSX-v as described in VMware’s NSX Network Virtualization Design Guide: “The Logical Routing capability in the NSX platform provides customers the ability to interconnect endpoints (virtual and physical) deployed in different logical L2 networks. Once again, this is possible due to the decoupling between network infrastructure and logical networks provided by the deployment of network virtualization.” Bottom line, much of what you previously needed a physical router for, you can now do virtually.

The NSX Distributed Firewall (DFW) provides, as expected, full firewall capabilities in a virtual appliance. An even more interesting feature of DFW is  micro-segmentation, or the ability to place a set of servers (1 or more VMs) in their own security zone and logically isolate them from other logical/virtual environments.

Again quoting the VMware NSX Design Guide: “In legacy environments, to provide security services to a server or set of servers, traffic from/to these servers must be redirected to a firewall using VLAN stitching method or L3 routing operations: traffic must go through this dedicated firewall in order to protect network traffic. With DFW, this is no longer needed as the firewall function is brought directly to the VM. Any traffic sent or received by this VM is systematically processed by the DFW.

“As a result, traffic protection between VMs (workload to workload) can be enforced if VMs are located on same Logical Switch (or VDS VLAN-backed port-group) or on different logical switches.”

NSX also provides a fairly impressive network load balancing service based on the NSX edge device. Some of the important supported features of NSX LB are special design for cloud applications, fully programmable via API, management through the same stack as all other NSX services, support for TCP and UDP applications, connection throttling, L7 manipulation and integration with third party LB solutions.

NSX L2 VPN service allows extending L2 connectivity across two separate data centre locations. Some of the use cases for NSX VPN Services, delivered through the NSX Edge device, include enterprise workload migration/DC consolidation, service provider tenant on-boarding, cloud bursting, and stretched application tiers.

Connectivity to the Physical Environment via NSX-v allows for the use of the physical network as a backbone, while allowing highly flexible, highly customised networking as an overlay. The use of the Virtual Extensible LAN protocol (VXLAN) enables the building of logical networks that provide L2 adjacency between workloads, without the issue and scalability concerns found with traditional layer 2 technologies.

NSX Spine and Leaf Use Case

The above diagram depicts a consolidated use case, which covers many different possibilities when using NSX-v. The architecture shown above is a modern spine and leaf construct of the type that I have recently been involved in utilising the following NSX-v features:

• Connectivity to the physical environment and the use of VXLAN
• NSX L2 VPN Services
• L2/L# Switching, Routing, Gateways
• NSX DFW and Micro-segmentation
• NSX Network Load Balancing

Conclusion

While VMware’s NSX-v represents a tremendous leap forward in software defined networking, there is still plenty to do. During a recent project, a few minor challenges arose, around how to integrate NSX into an existing physical infrastructure. The particulars involved my company’s security standards which required a physical firewall between the environment’s control plane and the user definable areas. VMware engineering was extremely helpful and the problem resolved.

As the product set matures and usage increases these issues will inevitably decrease.  What we have gained is much more cloud centric and feature rich software creation, control and change capabilities. Sure, there is still work to do to reach true SDN, but now we are that much closer.

(c)iStock.com/cherezoff

IT departments worldwide face a dizzying array of security threats, whether they manage traditional or NextGen/cloud based environments. IT security experts report some very frightening statics:

• Approximately 400,000 new malware instances are recognised daily
• New kinds of malware are gaining prominence including Ransomware, Scareware, and banking malware.
• New attack vectors include public cloud, software-as-a-service provider environments, third party services providers and mobile devices.
• Reports of politically or cause sponsored terrorism and corporate espionage are on the rise globally
• Increased use by hackers, of Botnets and other automated attack tools
• Recently a number of “foundational internet technology” based attacks have had a rebirth, including Heartbleed, ShellShock and Poodle.
• The targets seem to get bigger and the damage more costly as time goes by (ex. Sony, Target and Ebay)

The question is: how can today’s cloud service providers protect themselves and their customers while enabling technology innovation, data access, performance, scalability, flexibility and elasticity that are the hallmark of the NextGen/cloud world?

One of the great martial arts movies of all time has the main character, played by Bruce Lee, explaining that his style of martial arts is fighting without fighting, and then talking his would-be opponent into a small boat. Cloud providers would do well to emulate the intent of this “style” of combat.

Cloud service providers need to be ever mindful that they are targets and must monitor network traffic, application activity and data movement at all levels of the cloud environment without being intrusive or over-burdening the customer environments. For example, as in any technical environment keeping operating system and patch levels up to date is critical, but doing so in an efficient and non-customer-impacting manner is the trick.

Another important item to keep in mind is speed of reaction. In a cloud environment, more so than in traditional IT environments, the speed of discovery and closure of vulnerabilities as well as reaction to monitored attacks, is critical. 

Identify the layers

The first step in architecting a cloud security solution is to identify the layers of the environment to be protected. The following diagram shows the layers of a generalised cloud environment.

The layers of the environment mostly look like any tiered infrastructure, but the contents and components, as shown above, are quite different. Some of these areas, specific to cloud environments are:

• Hypervisor
• Virtual networking
• Virtual storage
• Orchestration and automation control plane
• Software defined networking (SDN) components
• Self service portal

Choose your protection methodology and tools

The next step is to determine how to provide protection for each layer. As an overall methodology the cloud instance should be considered a contained secure zone, as defined by firewall or proxy boundaries (virtual or physical). Once the secure boundaries are defined the majority of the remaining methods encompass monitoring and remediation of suspicious activity and malware protection.

An important point to keep in mind is that as service providers we cannot use tools or methods that access the customers VMs. The best example of this is malware protection. Hypervisor based malware protection is critical but actually touching the customer VMs breaches the boundary between provider and customer. There exist many options for the choice of the tool or configuration of the solutions presented below. 

• VIP: Providing a Virtual IP Addresses allows for network address separation between the external and internal net.
• SSL: Secure Socket Layer provides encrypted transport of HTTP network packets.
• Perimeter security (firewalls, load balancers, proxies): Creation of the boundaries of the secure zone and control of traffic flow between the external and internal networks. Firewalls, load balancers and proxy servers can be physical devices, physical appliances or virtual devices.
• Virtual services: This secure appliance or virtual machine provides update, patch and deployment services from within the secure zone.
• Network activity monitoring/IDS: Monitoring of traffic flows for intrusion detection purposes. In the cloud environment specialised tools to collect network data on a VM by VM basis need to be acquired or developed.
• File change tracking: Tracking of changes to important configuration files on the control plane and hypervisor layers.
• Log tracking and analysis: Centralised tracking of events from log files (ex. Syslog, cloud management component logs etc.), and analysis of those events for trending and detection of malicious activity.
• Hypervisor based malware protection: Specialised software (many on the market already) to detect and clean malware on the Hypervisor and on the physical device layers.

Looking at the above diagram and list of concepts, the reader may notice that there is no mention of inter-layer firewalls (e.g. between the control plane and the compute layer). This is because of the need to reduce intrusion and reduce performance impacts in the customer’s environment.

Developing a security management strategy

The most important element of securing any environment, not just a cloud environment, is an ongoing and ever evolving plan for maintaining the security aspects of the environment. This includes:

• Regular software updates – software vendors, including cloud management hypervisor, and security component providers will update their software regularly. These changes must be evaluated and appropriate updates implemented in an expedient manner
• Regular patching – As security patches and bug fixes are released from the software vendors, these must be a high priority for evaluation and implementation into your cloud environment.
• Centralised activity and security components monitoring – A centralised team of people, processes and tools to monitor and evaluate activity, and security alerts, in the environment. Centralisation allows for rapid event recognition and remediation.
• Scheduled and post-update vulnerability testing – Never rest of your laurels. An environment that is deemed secure today can be attacked in a whole new way tomorrow. Regularly scheduled vulnerability testing and testing after an update is applied can be critical in keeping the environment secure.
• Change management procedures and tracking – Tracking changes and comparing them to the results of file change scans is one step in identifying malicious updates. This will also assist in general issue resolution as well as remediation of a security event.
• Proper governance of the overall environment requires that processes and procedures especially around security are reviewed regularly and adjustments made as appropriate.

Conclusion

There are three key steps to preventing security vulnerabilities in a cloud environment:

• Identification of the layers of a cloud environment that could be vulnerable to attack
• Definition of methodologies and tools to monitor, manage and secure each of the identified layers
• Creation of a management environment to maintain the secure implementation of the cloud provision environment

No environment can be completely secure forever. Our goal is to reach a high level of security through the above methods and implement new policies and methodologies as time goes by, to attempt to keep up with the ever-changing threat landscape.

(c)iStock.com/4774344sean

Feature Cloud service providers find themselves in a struggle balancing responsibility for maintaining data integrity with delivering cost effective solutions to their customers, all the while protecting their own data assets and bottom line.

Generally, the type of service they are delivering limits a provider’s responsibility level. In the case of infrastructure as a service (IaaS) a provider might just be delivering infrastructure and a means of creating cloud environments with no provision of customer data backup. As part of a platform as a service (PaaS) offering backup and other forms of data protection may well be key selling points.

Basic types of data loss include data destruction, data corruption and unauthorised data access. The reason for these types of loss a varied and include infrastructure malfunctions, software errors and security breaches. Due to the complexities around data centre and cloud security, this article will deal destruction and corruption of data only.

Definition of data loss domains

There exist many types of data within a cloud environment – infact too many to enumerate. These data types can be classified into general categories or data domains. The importance of these domains, to the constituents of the cloud environment, gives rise to the concept of data loss domains or, who is effected most and how much impact is there if the data is lost. The above diagram represents the three major data domains; provider non-customer effective (PNCE), provider customer effective (PCE) and customer (CUST) and in the case of the provider domain examples of the types of data. This section will define the domains and the data types.

Provider data non-customer effective (PNCE)

The data loss domain contains information that belongs to the cloud service provider and has no effect on the customer. This information if lost or damaged will have a significant impact on the provider and their ability to conduct business.

On the other hand, loss of this data has little to no effect on the customers. For example if billing information were lost and irretrievable the customer would probably not mind. The obvious responsibility for protecting this data lies with the provider. The following is a short list of examples of PNCE data:

• Business management data
  – Billing and metering information
  – Service quality data
  – IT Benchmarking data
• Environment management data
  – Development/DevOpS data
  – Inventory and configuration management data
  – Performance and capacity management data
• Security data
  – Security systems management
  – ID management, authentication and authorisation data
• Logging data
  – System logs
  – Network activity logs
  – Security logs

Provider data customer-effective (PCE)

The domain represents that data which is owned by the provider and significant to the provider for business reasons (the provider needs to know how many VMs a customer has created) and significant to the customer as it defines their cloud deployment.

Both provider and customer will be impacted in the case of loss and responsibility – for protected the data is shared but primarily falls on the provider. For example, Virtual Machine configurations are the responsibility of the provider to protect but not if they are marked transient (the usual default state). If they are marked transient, then no protection is required. Some of the data types that fall into this domain are:

• Self-service portal data
  – Blueprints
  – Environment default settings
• Virtual infrastructure configuration
  – Virtual machine/compute configurations
  – Virtual networking (SDN, vRouting, vSwitching, VLAN, VXLAN)
• Orchestration and Automation
  – Provisioning and provisioning management
  – Promotion

Customer data

Customer data can take an infinite number of forms but constitutes the universe of data need to run customer developed and/or deployed services. The customer owns this data and is responsible for its protection unless otherwise arranged with the provider.  A customer may choose to have a cloud service provider replicate, back-up or otherwise protect customer owned data based on an agreement with the provider. These services generally take the form of a financial and service-level agreement between the parties. 

Preventative measures

Just because the IT world now lives, or is moving to the cloud, doesn’t mean that the rules of data protection have changed. We still need to measure Recovery Point Objective (RPO) and Recovery Time Objective (RTO) the same way that we have in the past. We still need to implement data protection solutions based on the balance of RTO/RPO, the criticality of data and the cost of implementation. We still tend to implement multiple solutions or multiple tiers of solutions to suit the environment.

The difference is, as we have shown above, who owns the data and who is responsible for the protection of the data.

There are some general categories of data protection methods that can be used, and should be considered in an effort to prepare an environment for minimized data loss. They include:

• Disk level data protection – This can be the old, and still best practice, of RAID based protection of disk resources. Another, option is Scale-out storage (ex. EMC Isilon, Nutanix) which spreads data across multiple nodes of the data cluster.
• Backup/replicated backup – The periodic backing up data to a lower tier, lower cost medium. The advances in disk-based backup and replication technologies have lowered the cost, increased efficiency and raised the level of recoverability of backup and recovery solutions.
• Data replication – Data replication technology has existed in one form or another for a number of years. Data written to one set of storage resources is automatically replicated, via software, to secondary storage. The problem for most of replication technology’s history has been accessibility and granularity. Technologies such as SRDF have always been highly reliable but the ability to access the data from primary and secondary resources and the ability to retrieve any but the most recent information were not possible.
• Journaled/checkpoint based replication – Enter journaled files systems and checkpoint based replication. This type of technology (e.g. EMC Recoverpoint) allows not only read/write access to either side of a replicated storage set, but also the ability to recover data at a point in time.

Protecting Data

Now that we understand the data and the means for protecting it we can now move on to the process for doing so. Two major steps are necessary for a cloud service provider to consider, classifying data and building a flexible DP environment. 

The following template can be used to classify the data that needs protecting:

Once RTO/RPO and criticality characteristics of the data are understood, an intelligent decision about protection method and frequency of execution can be made. For example if a data set has a low RPO (transactional) then replication with frequent snapshots might be necessary. If a data set has a high RPO (low rate of change) then low frequency backup should suffice.

The following diagram shows an example environment including data protection elements:

The combination of clear classification of data and a comprehensive data protection solution, including tools, infrastructure, processes and procedures should be a major goal of the cloud service provider. Planning and execution around these concepts will allow the service provider to remain fiscally responsible while maintaining their data protection responsibilities to their customers.