In case you missed it, the first phase of cloud computing has left the building. Thousands of companies are in the cloud. Practically all organizations regardless of size already have production applications in a public, off-premises cloud or a private cloud. Yep. Been there, done that.

And the vast majority of these applications use the classic “SaaS-style” public cloud model. Someone develops a useful service and hosts it on Amazon Web Services (AWS), Microsoft Azure, IBM Cloud Marketplace, Google Cloud Platform (GCP) or one of several other cloud vendors. Accessing this external service is typically performed via a well-defined API. Typically this API invocation is made using a simple REST call (or a convenient library wrapper around a REST call). This request originates from a web browser, native app on a mobile device or some server-side application and traverses the web. Using only port 443 or 80, it connects through a series of firewalls to the actual service running in the external cloud environment. The request is serviced by a process running in a service provider’s computing environment and returns a result to the client application.

read more

(c)iStock.com/franckreporter

A curious finding appears in the latest DevOps market assessment from Gleanster Research and Delphix: stakeholders have a strong definition of what DevOps comprises, but each definition varies wildly.

75% of the more than 2000 survey respondents agreed DevOps was either ‘strongly’ or ‘somewhat’ defined, yet when asked to pick an option, the consensus was less than unanimous.

The most popular definition (84%) for DevOps was “developers and system administrators collaborating to ease the transition between development and production”, while 69% plumped for “using infrastructure automation to facilitate self-service provisioning of infrastructure by development teams” and 60% opted with “evolving operations to meet the demands of agile software development teams.”

It is worth noting each definition offers plenty of overlap, and evidently more than one option could be chosen. Yet the report argues DevOps is ‘generally ill-defined’ and adds: “Some organisations view DevOps as an integral part of the day-to-day activities of the entire IT department. However, organisations with a stronger definition of DevOps tend to empower dedicated teams who are exclusively responsible for rolling out DevOps initiatives – and these are the organisations that see the greatest DevOps success.”

The survey also uncovered key drivers for DevOps initiatives. Faster delivery of software (66%) was the most popular choice, followed by identifying bugs earlier (44%) and delivering software more frequently (43%). Four in five respondents said they were under strong pressure to deliver higher quality software, spotting defects both during and after production, more quickly and with fewer resources.

Similarly, there is a discrepancy with regards to who leads DevOps teams. According to the survey, DevOps leaders argue development teams lead the process, while practitioners are more likely to note operations teams take charge.

According to a recent analysis from Rackspace, job roles requiring DevOps expertise continues to rise, with permanent roles posted increasing by 57% year on year, although at a slower pace than 2014, where job roles increased 351%.

Have we come to the point of guaranteed successful cloud migrations from/to almost anything for less than $1,000? That’s the promise of migration services specialists, WSM, which has successfully completed 250,000 migrations and based on that experience will start offering $849 fixed price server migrations.

read more

(c)iStock.com/Henrik5000

By Andrea Knoblauch

Over the last few years we’ve seen just about every part of the data centre move towards virtualisation and software. First we virtualised desktops, then storage, then even our security tools. So when the idea of software defined networking (SDN) started being floated around, it wasn’t a big surprise. But what exactly is it?

SDN’s early roots can be likened to the idea of MPLS, where we saw the decoupling of network control and forwarding planes. It’s also one of the key features in Wi-Fi, one of the most prevalent technologies today. But SDN isn’t just the decoupling of the network control plane from the network forwarding plane, it’s really more about providing programmatic interfaces into network equipment regardless if it’s coupled or not.

By being able to create APIs into these devices, we can replace manual interfaces and use the new software to automate tasks such as configuration and policy management, but also enable the network to dynamically respond to application requirements. Now you can deal with a pool of network devices as a single entity which means it is easier to control network flows with tools such as OpenFlow protocol.

So what does this mean for network folks? Well, first and foremost, SDN brings the promise to centralise and simplify how we control networks. It can make networks programmable and thus more agile when it comes to automation or enforcing policies. It also means that by having software at the heart of networking, it can keep up with virtualisation and cloud computing workflows.

Like a larger control console, SDN brings centralised intelligence that makes it easy to see the network end to end to make better overall decisions, and easily update the network as a whole rather than in segments.

Security folks will also benefit with advancements in SDN, giving them hopefully more insight into network issues, and quickly be able to respond to incidents.

The jury is still out when it comes to whether widespread adoption is ready for mainstream. There are still many startups driving this market, but the Open Networking Foundation (ONF), made up of board members from Microsoft, Yahoo, Facebook, Google and several other telecoms and investors are pushing for widespread adoption.

It’s yet to be seen what the true benefits of software defined networks will be, but the ability to adapt the network to different loads, be able to prioritise traffic or reroute, and of course the ability to see a better overall picture is reason enough for many organisations to start investigating this new methodology.

But the ability to start dropping in SDN for parts of your network and expand it as you change out of legacy gear is also going to get strong supporters who are looking for ways to reduce costs around gathering traffic and expand their network more with the returns on investment.

The post SDN: How Software has Re(Defined) Networking appeared first on Cloud Best Practices.

I am not sure how many people remember Cisco SANTap. About ten years ago, Cisco introduced a data tapping mechanism in the MDS 9000 fibre channel switches. The idea was to allow the data path to be “tapped” at-will. Tapping in this case meant using a mechanism in the switch to split the data being written from client hosts to the storage, allowing the identical “split” data to be routed through a second, separate path.
SANTap therefore allowed a copy of the data to be seamlessly “mirrored” through the switch and subsequently used by other applications for multiple purposes (especially for backup). It facilitated real-time protection of critical data, and allowed advanced functions such as migration, snapshots, etc.

read more