Getting to GIFEE with SDN: Demo

A few short years ago, espousing for open source and cloud computing was even more difficult than touting the importance of clean energy and the realities of climate change. The doubters and naysayers, vocal as they are, are full of reasons why things are (fine) as they are. Reasons, however, don’t get you results. We needed transformative action in IT, and today, as we’re right between the Google NEXT event and the OpenStack Summit in Austin, open source and cloud are the norm for the majority.

After pausing for a moment of vindication – we told you so – we get back to work to improve further and look forward, and a good place to look is indeed at Google: a technology trailblazer by sheer necessity. We heard a lot about the GCP at NEXT, especially their open source project Kubernetes, powering GKE. What’s most exciting about such container-based computing with Docker is that we’ve finally hit the sweet spot in the stack with the right abstractions for developers and infrastructure & ops pros. With this innovation now accessible to all in the Kubernetes project, Google’s infrastructure for everyone else (#GIFEE) and NoOps is within reach. Best of all, the change this time around is less transformative and more incremental…

One thing you’ll like about a serverless architecture stack like Kubernetes, is that you can run it on bare-metal if you want the best performance possible, but you can easily run it on top of IaaS providing VMs in public or private cloud, and that benefits us with a great deal of flexibility in so many ways. Then of course if you just want to deploy workloads, and not worry about the stack, an aaS offering like GKE or ECS is a great way to get to NoOps faster. We have a level playing field across public and private and a variety of underpinnings.

For those that are not only using a public micro-service stack aaS offering like GKE, but supplementing or fully building one internally with Kubernetes or a PaaS on top of it like OpenShift, you’ll need some support. Just like you didn’t build an OpenStack IaaS by yourself (I hope), there’s no reason to go it alone for your serverless architecture micro-services stack. There’s many parts under the hood, and one of them you need baked into your stack from the get go is software-defined secure networking. It was a pleasure to get back in touch with my developer roots and put together a demo of how you can solve your networking and security microsegmentation challenges using OpenContrail.

I’ve taken the test setup for OpenContrail with OpenShift, and forked and modified it to create a pure demo cluster of OpenContrail + OpenShift (thus including Kubernetes) showing off the OpenContrail features with Kubernetes and OpenShift. If you learn by doing like me, then maybe best of all, this demo cluster is also open source and Ansible-automated to easily stand up or tear down on AWS with just a few commands to go from nada to a running OpenShift and OpenContrail consoles with a running sample app. Enjoy getting your hands dirty, or sit back and watch demo video.

Those that want to replicate the demo. Here's the link I mentioned in the video: https://github.com/jameskellynet/container-networking-ansible

Automation is Killing the Knowledge Economy

Still standing at the top of 2016 for only a few more hours, January that is, I’m compelled to follow-up on my outlook on the rise of IoT and setting of the Information Age, with a forecast on the nearer-term workings of automation to slay the knowledge economy as we know it.

The push towards technological automation has allowed us do to more with less. Working in technology, I sell this vision to our customers everyday: better scale, more agility, go faster, spend less OpEx, etc. To be sure, automation has been a boon to business and consumers for a long-time, but it has also been a treacherous progress.

We have long-since been educated on the automation-caused job loss and redundancy to laborers in the manufacturing sector. Closer to home, you may have recently started seeing self-serve queues at your grocery stores. Okay you don’t work in a grocery store. It’s too bad for those poor clerks, but at least you’re safe. You have a university degree, expertise and experience. You work smart, not hard. You’ll be fine. Right?

Wrong! Today’s knowledge worker is dead. Many industries are already disrupted, and if yours isn’t already, it will be.

“Today’s knowledge worker is dead.”

I’m not talking about automation here in the form of robotics and the physical. Sure we’ve all heard about that dystopian future where robots do everything. Look already at the self-driving cars, or drones now that can deliver your mail, parcels and even coffee. That and more, is all coming too. But what I believe most people don’t imagine, is the redundancy that will soon be created in so-called desk and office jobs.

A good desk job in a nice glass tower and the honor of a white collar (maybe not in Silicon Valley) has been the reward of the knowledge worker for a long time. Today, automation is affecting these people too. However, a lot of these people are also shielded from the blade of automation. Why?

Let me briefly examine people that work in technology, as I do, as an example. A person goes to school to study computer systems, science and engineering, and out comes the quintessential knowledge worker in this space, the “geek” whatever the actual job title. Of those that go on to work closely with technology, in my mind, there are two kinds of these people: technologists and technicians. Sure, knowledge is critical to both of these types, but to the technician it is paramount. The technician is an administrator, operator, and integrator; thus, the technician’s job depends on their expertise and ability. The technologist, however, is a creator, an engineer of the technology that the technician will use.

Understanding the key difference between the technician and the technologist reveals something very important: knowledge alone is increasingly not enough. How can you immunize yourself against automation’s assail?

“How can you immunize yourself against automation’s assail?”

When automation has reduced the value of knowledge, expertise and ability, the prime determinant of success will be creativity. The technologist is a creator. Naturally, as for all creators, even artists, creativity must be used in service of skill and in the context of expertise. Yes, you still need to go to school to amass all of that knowledge and gain expertise and experience, but now you also need more.

This is why Google recruiters look for what they call “smart-creatives.” That’s why a lot of technical and non-technical desk jobs, the ones where you’re required to be creative, cannot be automated.

Now, is the time to practice being creative. Now is the time to align our education system for this creative future because automation is slowly killing the knowledge economy. Automation is wonderful and wicked, but I know such challenges it will cause, can be overcome with a creative solution.

You Have the Wrong Idea About Cloud If…

This year has been marked by a lot of cloud evangelism to our customers, partners and field, but what I frequently find is that in evangelizing cloud and our corresponding products, I am talking about what cloud is not. In the purist sense of “cloud,” I talk about cloud as 3rd-generation apps and platforms: the collective data center as the computer. For cloud-native apps and stacks, nothing need be server oriented anymore.

I was maintaining this summary list of the right and wrong ideas about cloud in my Google Keep notes, but I have decided to turn it into a blog: shared, referenceable, crowd sourced - yes please, add what I’m surely forgetting to the comments below.

As I said above, I’m often describing what cloud is NOT, and hand in hand with that go the wrong ideas about cloud.

You Have the Wrong Idea About Cloud If…

1. You want better economics without change – A common mistake is thinking that you can replace a few components with the software the cloud pioneers are using and you instantly save money. “OpenStack is not a cheaper VMware,” is a good one to repeat over and over to anyone falling into this trap, but you can generalize this advice too. If you don’t get your head around the fact that cloud is a whole new IT paradigm and 3rd-gen cloud platforms are the epitome of that, then you’re missing the point.
2. You want better economics from open source – Similar to the last point. This is a common mistake. For most cloud builders, you’re still going to need a vendor backing the OSS components, particularly mission-critical components like orchestrations systems such as Openstack or Kubernetes, and many Enterprises will opt for support in smaller components as well like for Linux, config automation, databases, troubleshooting tools, logging, monitoring, billing, analytics, etc. The point is that for production systems, you’ll probably want a lot of vendor support or support from an integrator, and while you may have a lot less lock-in, and more scale, there is still a substantial investment to build and support a stack these days. You can get better economics from cloud, but not strictly because you choose open source.
3. You think open source software is DIY – If you’ve just read the previous point, you know vendors support OSS and many integrators have businesses around OSS components. Open source can be DIY, but there are often a plethora of sourcing options for these that offer fully turnkey deployments, some even with the hardware as well. Choosing open sourced software, you get all the benefit of traditional support, plus the benefit of a community that can support you and offer you additional services and tangential products or customizations. It’s all upside, in general, but caveat emptor: that doesn’t mean you can adopt OSS willy-nilly. Today there are a lot of competing/overlapping projects and communities to carefully choose from. Many vendors will partially partake in some project, which is very different than productizing the core open source software itself.
4. You think cloud is less secure – Security doesn’t come your 4 walls. Public clouds have a lot of security baked in because they have had to thanks to being huge attack targets. They arguably had the smartest security talent design and validate it. When it comes to private cloud you have more security vendors (a lot of startups) providing you solutions than ever before. Microservices are inherently more secure by design when microsegmented into lightweight containers and virtual networks as well. A breach’s impact is getting ever smaller and unlikely if you follow 3rd-gen cloud architecture and employ the tools at your disposal.
5. You think the chasm is too wide a jump to cloud for your IT dept. – Today it is entirely possible to federate networking and data across your 2nd- and 3rd-generation platforms, and technology like Docker have really leveled the hybrid cloud playing field for compute as a sweet spot between IaaS and PaaS.
6. Your “Hybrid IT” strategy is to do everything – Sure there is a right tool for every job, but every good CIO values standardization and consolidation. The benefit of those principles hasn’t changed. You need to exercise restraint in choosing/building a 3rd-gen cloud stack, and get to something that can be as homogenous as possible across multiple DCs, public and private, and let you write once and run anywhere for apps and devops.
7. Shiny new object syndrome – If what you have today is working fine, refrain from wasting a lot of energy on the new shiny object. Run IT like a business and justify value in change.
8. You think cloud will solve all your problems – You'll just have better ones, and have to be even smarter and more resourceful to solve them.

You Have the Right Idea About Cloud If…

1. You need better/newer/choice technology – Just like if you’re running Android version X and the app you want is only available or supported on >X, you need to upgrade; or you’re running iOS and the app you want is on Android, you need to change. Likewise, apps/tools/middleware/etc. can be a good impetus to move/upgrade to cloud too. The case with a lot of cloud software is such that a lot of open source tools are made to work well with other open source systems, and 3rd-gen cloud systems and tools are primarily open source. Maybe it’s a choice middleware platform, or a big data system, or a config automation tool, but if you find yourself needing software from some Apache project, Hashi Corp, or some popular open source project, chances are it probably won’t work on or work too well with your legacy Microsoft, VMware platforms, but I bet you can find good integrations with OpenStack, Docker, or some public cloud.
2. You need better economics – With respect to public cloud you get to choose opex over capex which is often preferred. With respect to building your own private cloud stack you build smarter cloud-native applications and infrastructure layers that often let you spend less on the proprietary and expensive infrastructure solutions that were previously relied on to scale and provide HA. As above, that’s not to say openness directly derives better economics. The model of a smarter, more automated stack should help you do that, along with scale-out applications that provide a better and cheaper way to get scale, performance and HA. Better economics also comes from deriving more new value faster, which is a byproduct of innovation agility (see below).
3. You need scale – Hopefully this one is pretty obvious. The Internet giants pioneered 3rd-gen cloud stacks because it was the only way to scale their apps. 3rd-gen cloud platforms let you manage more with less. This smarter architecture is akin to using a lever instead of more force.
4. You need innovation agility– 3rd-gen cloud platforms cater to the developer and the application. The applications are elastic and portable across data center resources and geographies to suit the business. The developers have more conducive environments for CI and CD, and with Docker containers they have a level playing field of packaging, distributing, and running their app with all its dependencies. With PaaS and middleware platforms there’s often more ease and agility, but there is some degree of total flexibility traded. In any case with 3rd-gen cloud, time to market and to any necessary pivots is greatly reduced as compared to traditional siloed DCs and even evolving SDDCs. Avenues for business, process and product innovation are all amplified.
5. You have a mandate for openness – This is sort of a corollary from needing IT agility (which should be a consequence of needing business agility). The general allergy to IT lock-in is usually helped by the great degree of open source projects and open standards bodies/projects focused on making 3rd-gen cloud stack components clearly defined and interoperable. The best clouds are inspired by the same principles of as UNIX components: small, simple, reuseable, composable parts with clean interfaces, and as few dependencies as possible.
6. You have no technical debt / You are building new – If you are a startup you should use SaaS for your staple IT applications and otherwise start from scratch with modern IT cloud-native apps and cloud. New infrastructure for new apps, dev/test, etc. is a green-field, and you should be growing with modern choices.
7. You want to attract new IT talent – Another gimme. Legacy technology is an oxymoron because technologist and technicians alike love what is novel and remarkable.
8. You want to get teams smaller toward DevOps – Sure, on cloud, you can do more with less, including fewer people if you’re operating at massive scale, but on any scale the main ”people” benefit is actually a better-working well-oiled IT team culture. Some companies’ idea of DevOps is no change at all – maybe Dev meets with Ops every month – dev talks to ops :/ A 3rd-gen cloud stack forces the DevOps culture of teams working together by means of programming and debugging each others’ subsystems in times of development, testing, troubleshooting, and operations. Much like the microservices architecture, devops and 3rd-gen cloud caters to small nimble teams if you follow the masters like the internet giants’ two-pizzas rule.

Again… please, add what I’m surely forgetting to the comments below.

This blog was originally posted on the Juniper Networks blog.