THE DOPPLER

Our guest on the podcast this week is Tom Shinder, Program Manager, Azure Security Engineering at Microsoft.

We discuss security in Microsoft Azure where they have a mindset of assumed breach. How we've historically done security is we have looked to build more walls, moats, and force fields to keep the bad guys out. We've spent a long time building walls, but they can be hacked and they have. We should not stop prevention efforts, but what we should start to assume you have already been breached and be ready for that. When you assume you've already been breached, then focus on detection is critical. The average attacker has been in your system for 280 days before they have been detected, which gives them a lot of time. The goal is to reduce that time to a few days.

We look at Microsoft Azure Active Directory integration. This is meant to be used when deploying new applications into the cloud. Many of these tools allow developers to be able to focus on what really matters instead of focusing on putting out fires.

Microsoft is currently creating improved security standards, starting with a PCI template to help enterprises with regulations.

Encryption can sometimes be difficult with the Key Vault process. Microsoft is aware of some of the challenges and is working on revamping documentation for Key Vault to ease the difficulty. It is a great service that can make life easier, which is why the documentation updates will help make the product more accessible.

Azure Security Center allows you to control you security from one place, and gives recommendations and alerts based on anomaly detection. For hybrid deployments, there is a solution coming soon from Azure Security Center.

Our guest on the podcast this week is James Staten, Global Head of Vertical Market Development, Strategy & Planning at Equinix.

We discuss what serverless computing means for OpenStack private clouds. It is time to recognize that hybrid is here for a long time and we will be mixing public clouds with private clouds in the long run. We also look at Red Hat's recent deal with AWS for OpenShift. This is another example of coopetition with AWS, which has sought out many more partnerships lately. Vendors are finding more opportunities to partner with AWS to prevent themselves from losing customers.

Our guest on the podcast this week is Adrian Bowles, VP of Research and Lead Analyst, Artificial Intelligence at Aragon Research.

We discuss how sometimes you can find more impactful insights from smaller boutique research firms than the larger giants. Aragon Research is a full spectrum industry analyst research firm who provides advisory services to those who are building, buying, or investing in emerging technologies.

We take a look at the latest announcements Amazon CTO Werner Vogels made at the latest AWS Summit. We look at new SaaS contracts in the AWS Marketplace allowing smaller SaaS companies to outsource their billing to AWS.

Amazon is a company that seems to keep doing things right. They are hard to avoid as leaders in cloud computing right now. Even when they make mistakes they seem to be able to pivot them quickly into useful tools. They own somewhere around 80% of the public cloud market at the moment and it is no surprise why because they have the best technology.

We also look at Amazon CodeStar, their improved database services, and upgraded machine learning tools such as Amazon Rekognition.

Amazon Rekognition uses machine learning for image detection to automatically monitor content. This allows us to identify objectionable images automatically. This has use-cases anywhere from identifying fake news to preventing issues with advertisements on objectionable content. Amazon is using machine learning to look at images and rank them on a 9-point scale of how objectionable the image is.

Rekognition is a deep learning service, meaning it is built on several layers of neural networks, the first layer being feature recognition, the next a classification of objectionable content, and so on. As of now, Amazon has built in a standard scale, but it would be interesting if they let users choose their own parameters for what is objectionable. Giving context for content is a difficult step in the process, which would be an interesting next move for Amazon also. There needs to be an objectionable rating for users so that the system can learn individual preferences as well.

We also discuss data privacy, and how zombie cloud data can haunt you when you think it has been deleted but it still exists somewhere else. There are legal issues around this zombie data that are being exposed now even with subjects like student standardized testing. Of course, sometimes this can be a great feature when you accidentally delete something and there is a way to find it again.

Our guest on the podcast this week is Ed Featherston, VP, Principal Architect at Cloud Technology Partners.

We discuss how a lot of big players in tech from the past are now gone, and this trend makes us look closely at the big tech companies today whose growth is slowing, such as Oracle and IBM. They seem to have lost their disruptive edge and struggle with the new business models they compete against, but experience tells us they are definitely survivors. They're making money around a legacy business that we still live with today, but that is diminishing with the widespread adoption of the cloud. If they do move into the cloud, which they have taken steps towards, it doesn't necessarily make sense because they would be taking sales from their own legacy technology.

IBM is now reinventing how to work within this new type of model that Microsoft and Amazon have built. IBM is trying to play catch up on the growth of the cloud and figuring out how to make money on it. With Watson and IoT, they are doing fascinating stuff in this space which could launch them into a hybrid cloud model with various customers, but there is no question they are struggling.

We look at how AWS is looking to simplify building and deploying apps on the cloud platform with a new service, AWS CodeStar. This service makes it simpler to set up projects by using templates for web applications, web services, and others. Developers can provision projects and resources from coding to testing to deployment. It seems to be yet another service AWS is providing that Microsoft and Google don't have, which further solidifies its leadership in cloud computing. Amazon is great at targeting clients at all levels, from large enterprises to capturing the minds and hearts of the tech geeks. With AWS CodeStar, they aim to make it easier for developers to build applications on the cloud. 2017 is the year of the cloud land grab. Each vendor is trying to get as many people onto their platforms as possible, and AWS is trying to convert anyone and everyone.

AWS CodeStar was launched in response to enterprises facing the challenges of agile development software processes. The first challenge for new software is often having a lengthy setup process before they can start coding. The ability to pull this stuff out to the cloud and get up and running quickly is a huge strategic advantage, especially considering enterprises cloud take years to set up processes like these.

When an enterprise decides to switch to agile development or DevOps, there is a huge initial infrastructure setup involved to get the ID setup, the code repository set up with right security, and getting the build and deploy systems created. By Amazon offering this in a box, giving end-to-end solutions including integration with JIRA for bugs, that will be huge for saving time and headaches for clients. It would not be a surprise to see the other cloud vendors start to imitate CodeStar now that AWS has raised the bar.

Amazon has in a way become the new IBM. They are now the 800 pound gorilla that others strive to catch up to. When you look at their total capacity, they have close to fourteen times the data capacity of the next five vendors underneath them. It will be hard to catch up with them. Other vendors often claim to have faster growth than AWS, but that is only because they are playing on smaller fields and AWS is so big there is less room to grow.

Microsoft is now offering Cloud Migration Assessment services, which walk clients through an evaluation of resources they currently use to determine what to move to the cloud and what it will cost to do that. AWS offers a similar tool, and it's clear that both tools will be used to promote their internal products. It may be a useful tool to determine the cost of migrating to the cloud, but it's important to remember that everybody's needs for the cloud are different, so enterprises need to focus on what their particular needs and requirements are.

No technology negates the need for good design and planning, and cloud is no exception. The pricing of moving to the cloud is dependent on how your particular IT is structured. Cross-vendor pricing must be considered also. Your particular configuration will depend on your requirements and what vendors you are piecing together. These tools often underestimate the cost of what the migration will be, they would rarely overestimate the cost.

Our guest on the podcast this week is Richard Seroter, Senior Director of Product at Pivotal.

We discuss the transition from the popularity of Service-Oriented Architecture (SOA) starting in the early 2000's to today's microservices. SOAs were API-based which made it easy to pivot into cloud computing. With SOAs we used to think reuse was a goal, but with microservices it has become much easier to replace everything. With microservices you are often trying to decompose as much as possible to increase speed.

We look at Pivotal and how they help large companies get good at software. They do that with agile methods. Pivotal Labs used to help large companies like eBay, Twitter and Google get ramped up on agile development. There is a lot of money going into disruptive technology today and everybody is at risk of losing their place to someone who does software better. It changes the game for these large enterprises who realize that if they can get their software skills competitive, their advantage of history and supply chain comes back to the forefront. The service experience now starts with software. Pivotal is a trusted advisor to come in and help big companies make these changes.

We also explore updates in Cloud Foundry and Pivotal Cloud Foundry. Last week an update added full Windows support under the cover of Cloud Foundry. Pivotal has been working on not only bringing in the Windows ecosystem, but also supporting more types of workloads, container networking for container communication, and persistent storage. Pivotal is checking the boxes from traditional PaaS to a cloud-native platform which runs anywhere and brings more types of workloads in. There are more types of applications because most of these companies need to improve their software capabilities, but do not necessarily need to get good at infrastructure internally. Offering more types of apps and services in more places to help these enterprises improve their software practice is important. These are all ways to make developers more productive while also simplifying the ops burden, which is not easy. Learn more about Cloud Foundry at the Cloud Foundry Summit in June.

Microsoft recently acquired a small startup, Deis. Sometimes acquisitions of smaller companies can be more of a mystery than large ones. Deis powers Kubernetes on Azure, so it looks like this acquisition is most likely a mix of an acqui-hire and a purchase of technology relevant to Microsoft as they improve their Kubernetes capabilities. It seems they are doing everything it takes to get as many interesting workloads on Azure as possible. Large companies like Microsoft, AWS, Google, and IBM can't move fast enough, so getting the technology they need to differentiate themselves will start to happen more and more. It looks like we should expect to see many more acquisitions to come and further consolidation in the industry.

Last, we look at cloud security and whether we need to encrypt everything going forward. Many major websites already encrypt by default, encryption and multi-factor authentication need to be used everywhere. If we do encrypt everything, it adds latency in how information is moved from place to place and it annoys people to have to do extra steps. But we seem to be moving in this direction quickly. On the cloud, there is no performance latency as we move in this direction anymore. By default, we should encrypt everything from now on. Assume every piece of information from now on is going to be hackable.

It is not possible to simply lift-and-shift and assume it will be okay anymore because the legacy apps were designed to sit behind a firewall and all the inter-app communication was secure only behind the wall. Instead we're moving to a model where every component needs to protect itself, encrypt its own data, secure access into it, and authorize the user on the way in. If you're not doing those things it will be hard to pick up a legacy app and run it in the cloud somewhere because the security wasn't built for that. Luckily, cloud services make this process easy and most public clouds have encrypted databases, but companies are not always ready to handle that. As platform builders, if we can simplify this, we will get farther with developers and have less data leaks and bad practices.

Our guest on the podcast this week is James Markarian, CTO at SnapLogic.

Data integration is going through a Renaissance at the moment just like application integration did a few years ago. The primary driver for these changes is the movement to the cloud. When you turn back the clock, application integrations used to be simple. There were a few ERP systems, and as things started moving to the cloud via SaaS, application integration changed quite a bit. Now we're seeing analytic applications move to the cloud as well. The biggest force of gravity is the mass movement to the cloud. That is also driving data integration. By definition, we're now replicating platforms as much as we are moving into them. Enterprises that are moving into the cloud need a parallel data application integration strategy to make use of your data as an asset and to make sure the overall plan will work.

Data is frustrating to deal with. The problems seem easy and the reality is hard. Normalizing data, merging it together so you can get meaningful results out of it, making sure your SLAs are met in terms of freshness and quality are all easy to describe but are frustratingly hard to do. One of the challenges we have for on-premise systems is there has always been a goal to democratize data. The challenge is access. It sounds easy, and the cloud inherently breaks this democratization barrier. There is now a public place where people can go get access to data. That centrality is driving a lot of innovative capabilities we are seeing emerge.

Going from legacy applications to cloud requires a different approach to application and data integration. One starting point is choosing a cloud platform and trying to pick the right one. This can be the toughest decision a customer faces. Within each cloud platform there are also myriad choices, from which query technology to use, to whether to use Hadoop implementations on Azure, and more. There are so many choices and it's easy to feel like you've made the wrong one.

Working in enterprise IT, there is a shift in the view of how data should be managed, accessed, and manipulated. In the early days, it was a developer's job. IT was the team who knew how to access data and application systems. Self-service pushes some of the responsibility out to the edges. It's not about wanting to move away from IT, but it's about empowering those who who have the domain knowledge and will eventually be using the data. How we access these systems is different now. The structure of the data is also different. It used to be row and column-oriented. Nowadays, with REST and JSON, being able to handle the formats and not create new barriers so you are not manhandling the tool into dealing with data in unnatural ways. That will make developer lives easier and make it easier for vendors to add connections to the data.

Databases used to be relatively simple. These days it's often special-purpose databases such as in-memory, object-based, hierarchical, and relational databases. In some ways this makes things more complex, but with layers of abstraction it can also make things easier. When we only had relational, you had to make data look relational whether it was meant to or not. Now you do not need to force anything to fit different data sets.

SnapLogic is beginning to leverage AI and Machine Learning. Their focus is on making computers work for you instead of making you work for computers.

Our guest on the podcast this week is Kelsey Hightower, Developer Advocate at Google Cloud Platform.

We discuss the birth of Kubernetes at Google and how it started as part of Google's own best practices and infrastructure, then was created into an open-source project and shared externally. It was a brand new code-base, but built based on Borg, which was an internal system at Google for over 10 years. That is why Kubernetes has a lot of design aspects of a more mature project. It is a combination of Google's past work on containers and the new container ecosystem related to Docker so that Kubernetes can work outside of Google in any environment. Anyone can get involved and start contributing to the system. There is no enterprise version of Kubernetes, there is just Kubernetes and the different vendors and providers add value to it.

We look at the announcements from Google NEXT. There were no Kubernetes surprises because it is developed in the open, so everything you want to know about it is actively tracked on GitHub. Instead, at Google NEXT, they tried to add clarity about why Google is working on specific features like dynamic storage provisioning and custom schedulers. It's clear Google is evolving into the enterprise cloud space and they are committed to staying ahead of the curve. For Google Cloud, that means opening up some of its core technologies such as TensorFlow and Google Cloud Spanner so that enterprises can begin to consume Google technology.

We look at Amazon's recent decision to allow customers with Reserved Instance contracts to subdivide some of their Linux and UNIX virtual machine instances and still keep their capacity discounts. This decision was made so that Amazon could keep up with Google on flexible pricing. These types of changes are evidence of a healthy marketplace. A lot of times people try to mimic the spending habits of traditional enterprise IT which require a three-year roadmap, which is the opposite of what cloud should be. Cloud should be a dynamic world where you can scale-up and scale-down, which is why discounts should kick in based on behavior and actual usage. It's also why Google has per-minute billing. In this way the pricing structure matches the dynamic needs of cloud computing.

Last, we discuss how small to medium-sized businesses in India can get subsidies for cloud adoption, while the US wants to tax its usage. This may be an opportunity for the US government to offer tax breaks for cloud adoption to incentivize change so that we can use these resources more positively. Some enterprise clients view cloud computing as a complex expensive endeavor. In essence, they're right, they have archaic infrastructures and it takes a lot of work to move them to cloud, so some of the work it takes can remove the incentive to make the switch. In order to get them over the hump, they need to understand the cost savings, but it seems like a step in the right direction to provide tax incentives much like buying a Tesla can be subsidized. That should at least send the right message to companies in the US. Cloud adoption reduces data center space, saves electricity, and helps build businesses faster, which seems like a win-win for large enterprises and the US government.

Our guest on the podcast this week is Ray Young, VP at Cloud Technology Partners.

We discuss the AWS outage and how it should not come as such a surprise because cloud provider outages should be expected from time to time. For a lot of companies, the outage was a wake up call not to move away from cloud, but that they need to make the right architectural decisions about the cloud to prevent these sorts of outages. worrying about outages is not the answer – it's all about management, monitoring, and the ability to have self-healing capabilities. Cloud providers will have outages from time to time, and your enterprise's cloud architecture will make the difference.

We also discuss digital innovation in the cloud. There are many 'me too' players jumping into the cloud, following others with the same solutions. Not a lot of people are thinking out of the box and doing new, innovative things. For instance, it seems like AI as an industry is not innovating anymore, just implementing the same technology to solve similar problems.

Traditionally, when IT has talked about cloud adoption the focus has been on how to shift from data center mindset to infrastructure as code. But more and more, there is a real driver for cloud adoption to be innovative. The primary way cloud makes innovators is by allowing them to stay relevant and survive in today's technology world. There is also a shift from loyalty of a brand based on the merits of a brand versus brand loyalty based on customer experience and engagement. The cloud is where innovation and agility is happening on customer engagements. Customers are now making investments in the cloud for cost savings as well.

Large enterprises now see their competition as small, nimble, emerging startups. These startups are able to mature their capabilities through their investment in cloud, SaaS, and custom-builds on the cloud to be seen as an equal in the marketplace. For large enterprises trying to stay relevant in a marketplace of startups who can move faster than they can, cloud is the only way to equalize the playing field.

Our guest on the podcast this week is Scott Udell, VP of IoT Solutions at Cloud Technology Partners.

We discuss containerization orchestration technologies like Kubernetes, and the healthcare industry's complex relationship with cloud computing.

We look at the reasons to use Kubernetes as a containerization orchestration tool. Kubernetes represents about 80% of the orchestration tools that exist. The market position is known, skill-sets exist for it, it can scale, and it can provide a one-stop shop to do something effective with containers. In all, companies are not doing a lot of containers today, it is still a small part of the cloud, but it will continue to expand rapidly.

We also look at the healthcare industry's complex relationship with the cloud. Healthcare is behind the curve in terms of how they're leveraging technology. The amount of automation that can occur and good that can be done with technology in the healthcare industry is immense. They can move a lot faster with moves to the cloud.

Our guest on the podcast this week is Gene Kim, DevOps expert and author at "The Phoenix Project" and "The DevOps Handbook."

We discuss "The DevOps Handbook", which was started over five and a half years ago and released in October 2016. Gene co-wrote the book with Jez Humble, Patrick Debois, and John Willis. The book includes over 48 case studies that range from unicorns like Google, Amazon, Facebook, but also horses like Nordstrom, Target, and Capital One. Many of the case studies came from the DevOps Enterprise Summit. The book has discussions of both greenfield and brownfield deployments, even touching on mainframes.

The most common question enterprises ask about DevOps is: Where do we start? "The DevOps Handbook" starts with a chapter on starting with DevOps by picking the right value stream. The research started by looking at where successful unicorns and horses started with their DevOps initiatives.

They also look at the failed DevOps initiatives to learn what to avoid. Failures can be categorized in two ways: starting too small or starting too big. Initiatives that start too small often start with a simple Chef or Puppet project end up looking like like more of a hobby. When they finish the project, they haven't actually proven anything and the project gets easily dismissed. Initiatives that start too large often choose something too critical to the operations of the organization, and is unforgiving of mistakes. The most successful journeys start with something that creates a material contribution to the organization, but is small enough that it does not get shut down early for small mistakes. Their studies found that one out of three leaders who were starting these transformations were being promoted for their contributions.

There is no one answer for how to change an organization's culture for DevOps, but there is a prescriptive set of guidelines. The technical practices do not change such as version control, continuous testing, continuous integration, automated deployments, proactive monitoring of the production environment, security integrated into every step. What is different is where these initiatives start from. Some come from the Director ofr Operations, a Chief Architect, or even Director of Development. This transformation starts from different people and teams at different organizations. There are many different ways to reach a great DevOps practice.

The three guiding principles of DevOps are:

• Flow : Maximizing the flow of work and minimizing the lead-time
• Feedback: Creating check-ins and the equivalent of being able to stop the assembly line
• Culture: Fostering a culture of continuous experimentation and learning

There is a myth that with DevOps you can't have any central control. We discuss differences in self-service teams like Netflix and Amazon to function-based teams used at Google and Disney. We look at Etsy's liason model assigning ops engineers to various service and product teams. Many companies do well with the technical aspects of DevOps, but struggle with the culture changes it requires. Ten years from now, it will be about creating learning organizations and the command and control model will not be effective. It won't be about who caused a problem or who to blame, but will be about creating a culture of learning for a successful team.