Safety at Speed Podcast: Recent Episodes

Elliot Murphy

Over the last few years I’ve become convinced that we need to share more stories around security and compliance so that people can both have a less stressful work environment and do a better job of safeguarding data. That is why I created the Safety at Speed Podcast.

The show is meant to collect stories, lessons learned, and ideas for how to cope with regulatory demands for privacy, security, and compliance in DevOps without being miserable or preventing innovation.

Sponsored by KindlyOps This show is brought to you by KindlyOps. Learn more at KindlyOps.com

View Details

In today's edition of the Safety At Speed Podcast, I spoke to the co-founders of Corgibytes - Andrea Goulet and Scott Ford. The goal of Corgibytes is to help different groups and organizations modernize their existing software applications. In many cases, organizations have existing programs that they have been using for a long time, and which provide a ton of value, but are not always easy to work on. Corgibytes cleans everything up, and makes it more modern and secure. They call themselves the “Code Whisperers”.

As a company that works with sensitive data – such as customer information and intellectual property – Corgibytes has had to overcome some obstacles when working with their clients.

The Biggest Issue They Face Is Trust

One of the first obstacles that Corgibytes faces is getting clients to trust them. In many cases, clients are unwilling to let an outside company take a peak at their applications. Since so much of their business relies upon these applications, it is a little scary to allow someone else to access it. Not only are there intellectual property concerns, but stored customer data is also an issue. If customer data was ever leaked or exposed, it would create a large issue for their client.

To combat this, Corgibytes has started using different security and legal methods to help ease some of their clients' worries. One such method is to allow the client to set up their own virtual environment. This way, Corgibytes completes all of the work within an environment that their client controls.

Security Costs Can Get In The Way

Because Corgibytes is often dealing with sensitive information, their clients require all sorts of different security measures. In one instance, a client wanted an armed guard to be in the room where the work was being performed. However, since Corgibytes employees all work from different locations, this made it unfeasible. It would have simply cost too much to hire an armed guard to be stationed within every coder's home. Andrea and Scott say that they are usually able to work out a compromise with their clients, but in some cases the required security measures simply make that impossible.

As Andrea says “In order to move fast, and in order to get the value that we're promoting, we have to have a limited burden. It's finding that place that is right in the middle.”

Corgibytes Places An Emphasis On Self-Care

Andrea believes that “the biggest security risk are people who are burning out.” Scott told a story about his time working in aerospace, when a safety officer would shut down missions if he sensed the crew was getting tired. Anytime someone suggested “powering through” this was a warning sign that they needed to end for the day. This experience taught Scott that human factors matter, and that ignoring them has consequences.

To address the issue of tired employees, Andrea and Scott have implemented a few policies to ensure everyone stays fresh. For starters, they allow their employees to pick the number of hours they want to work each week, and adjust their pay based on their selection. In addition, there is not a set time that you need to work, you just need to finish your hours by the end of the week. They also offer virtual yoga classes to help their employees relax throughout the day.

They Plan For Mistakes

Even though they take measures to prevent their employees from making mistakes, they know they are going to happen anyway. Andrea and Scott have implemented a two-pronged approach for dealing with mistakes – the first is to have systems in place that minimize the impact. They plan for easy rollbacks, and have systems in place that constantly monitor for issues, so that when something does happen, they can fix it quickly, and right away.

Secondly, when a mistake does happen, they don't focus on placing blame. They believe that placing blame only leads to fear of mistakes, which in turn creates even more mistakes. Rather, they try to find the reason that the mistake happened, and how they can prevent it from happening again.

They Want Security To Be More Continuous

Finally, Andrea expressed a desire for security measures to become more continuous in the future. Rather than having a set level of security for each project, it should vary based on the stage of the project. Based on the work flow, security could be dialed up or down to fit the circumstances. As of right now, one of their biggest challenges is knowing how much security is actually needed, and finding a way to balance costs against these needs. A continuous approach to security would allow them to better address their needs, and be more cost-effective.

Tools That Corgibytes Likes

  • Circle CI
  • Honeybadger
  • Hackerone
  • Sonatype

Find Andrea and Scott Online

  • Corgibytes.com
  • legacycode.rocks
  • slack.legacycode.rocks

Scott on Twitter - https://twitter.com/mscottford

Andrea on Twitter - https://twitter.com/andreagoulet

View Details

“Ecosystem: a biological community of interacting organisms… a complex network or interconnected system.” —OED

At KubeCon 2016, Elliot had a moment to speak with SAP Labs' Nishi Davidson about some of the driving principles behind large-scale adoption of Kubernetes at SAP. Ecosystem partnerships tend to spring organically when thought-leading organizations agree that the same set of problems needs to be solved. As Nishi points out, secure, orchestrated service scaling is definitely one of those problems.

“Security scares the hell out of people,” she says. “The orchestration layer is up for debate, and sometimes people have [their own] views… but as far as security is concerned, everybody wants to collaborate.”

It's a jungle out there. In this episode of Safety at Speed, Elliott and Nishi discuss isolation in the world of bare metal applications, improving control while reducing cost, and embracing open source as a necessary tool for survival.


E: Hi, Nishi. Can you tell us a little bit about yourself—who are you, where you work, what your background is?

N: Sure, Elliott. I work at and represent SAP Labs, which is a research group in SAP that focuses on best practices in infrastructure and cloud delivery. We work with a lot of lines of businesses at SAP, as well as software product groups, and we introduce best practices with regard to cloud.

E: That sounds like a really complicated job in a demanding environment.

N: Yes, it is. Extremely complicated, and it's always difficult to work in a company where there are varying viewpoints, and try to introduce something that's innovative, good, stable, and is in the right direction.

E: Yeah. So, I went to your talk yesterday. We're here at KubeCon, which has a thousand people attending, so much bigger than last year, and next year they're planning for three thousand people.

N: Yeah.

E: This entire ecosystem around Kubernetes is forming, and a theme that I'm seeing here at the conference is that large businesses and enterprises have been using Kubernetes. Why is SAP interested in Kubernetes?

N: So, there are a couple of reasons.

From a technology standpoint... SAP has a very strong development culture. The German heritage always has been focused towards engineering, and SAP founders themselves are extremely engineering-focused. So, from a new technology perspective, a lot of change in SAP comes through the development community. And Kubernetes in general has a huge background in being developer-friendly, and it actually has a huge Github community out there, and a lot of developers inside of SAP believe that the clarity in thought and the design that Kubernetes provides, is very well-suited to the environment. So, that's one: developer perspective.

Second is, most of our applications that have been extremely successful in the market are built on Linux, and they've always had a foundation on Linux. They run on bare metal, and they're not Windows-friendly so if you think about it, the logical answer to isolation and to resource management will be containerization, not so much virtualization. And therefore the technical group in SAP is highly excited about the development in Docker, in Rocket, and we definitely want to forge ahead in that [direction]. And Kubernetes falls squarely in the zone of open source, which is very favorable to us. So, those are two of my top technical reasons.

From a business standpoint, if you look at the business drivers for our executives, they're concerned about stability. Stability for our SaaS lines of businesses. They're also concerned about growing costs, and trying to make the costs go down—as the company is really, really huge. And, from those two standpoints, if you actually start adding up the infrastructure cost—from server, from storage, from switches, and then Pylon, virtualization, the cost of the operating system, monitoring, logging... it is tremendously expensive. So we as a group have looked at OpenStack as being the centralized orchestration layer, because we believe in open source. And the obvious choice is to look at Kubernetes as well, because we think that eventually, from a business standpoint, it's going to bring costs down—and we all know Google is a leader in technology, and we believe that their design is going to be superior.

E: Yeah. That makes sense. Give us a sense of scale, working inside SAP... how many developers are working with the systems there? Maybe not necessarily using Kubernetes today, but over the entire business, or set of businesses, how many developers are we talking about?

N: So, until yesterday, I thought there were probably—forty people? Today I think there are probably 100-plus or 200 developers in different corners in SAP working on this. Primarily because I met my colleagues in Concur, they have a full system running...

E: ...and that's a business you acquired.

N: That's a SaaS line of business, and they've been deploying clusters after clusters in their operations environment. They told me that they've been meeting teams all across SAP—in China, in Germany—that are working on Kubernetes. In fact, an extension of our team that leads the OpenStack development also runs their complete control plane on bare-metal Kubernetes. So, we basically have a control plane that develops OpenStack components like Nova, and Swift, and all of these components inside of containers. So, I don't know. I think it's crazy large!

E: Yeah, that sounds huge. I mean, a company that is so big that you only discover other parts of the company by meeting them at a conference...

N: Exactly!

E: ...is pretty big.

N: And it's so exciting to like, meet people who are like-minded, and who believe in Linux, and who believe in open source. It's fantastic.

E: Yeah. So with a company that large, particularly one that has grown through acquiring other companies which had their own ways of doing things, and their own cultures and processes developed—what sort of interesting or thorny challenges have you run into as you try to balance security and stability, and at the same time you're tasked with introducing change and making things ready for the future?

N: As far as our multiple lines of businesses are concerned, the challenges that we face are tools that people want to use in order to deploy containers—so, some are interested in Kubernetes, some are interested in HashiCorp portfolio, some are interested in Mesosphere. That being said, the majority are looking at Kubernetes for the reasons I just described. As far as security is concerned, that's an area where people are willing to collaborate and learn from each other... security always scares the hell out of people.

E: Absolutely.

N: And we all, if somebody finds a better way to help us work with SELinux, or do something different that allows isolation to happen in a better manner between the kernel and the containers, we're willing to listen to anyone. So the interesting part is, the orchestration layer is up for debate, and sometimes people have views—orchestration of containers, and what monitoring tools you use, blah... but, as far as security is concerned, everyone wants to collaborate.

E: Yeah.

N: So, I think going forward, even if we pick SELinux as the right direction to go forward, it's a little difficult to handle and easily work with. And we across SAP are going to collaborate in terms of how we do the security aspect of containerization and container orchestration.

E: When you're successful introducing this whole new set of tools, whichever particular tools end up being selected, will the rate of change be faster or slower inside the company?

N: I think the major thing that's slowing down the process of adoption is containerization. Most of our applications are running inside VMs, believe it or not. Even though it's built for Linux, most of our applications are running inside VMs. It works, and we have -- a majority of the resources in the company know how virtual machines work.

E: Sure.

N: So therefore, from a resource training standpoint, and from a “fixing today's problem” vs. innovation standpoint, people are going to take slow steps towards containerizing all their applications. But once that hill is crossed, you know... you start containerizing some big applications like KANA, or some of your larger applications inside your line of business—human capital management, ERP, S4/HANA, it's just going to be adoption at a skyrocketing pace. Because really, Kubernetes and the community is giving you an infrastructure, orchestration, monitoring, all of these infrastructure platform tools, but they can't containerize your application. That's something that you have to do. And once you do that? There's no stopping it.

View Details

In this edition of the Safety SB Podcast we talk to Brandon O'Larey, the Director and Editor of FRANK. As the Director of a small business – and one that relies heavily upon digital data – Brandon is in an excellent position to discuss the security challenges facing small businesses today. Brandon told a few stories about the problems he has come across, and lessons he learned along the way. Below are a few of the questions we presented to Brandon during our conversation.

What risks do you face in your daily work?

Brandon tells a story illustrating why he always asks for payment upfront, and how he has learned to protect his digital files while on the go.

What precautions do you take while traveling overseas?

Theft is more common in some of the locations Brandon visits for work, leading him to take out insurance and pack his gear accordingly.

Have you been in a situation where security measures actually made things riskier?

Brandon once worked with a company that had been the recent victim of a ransomware attack. As a result, new security measures were implemented – some that made things better, and some that made them worse.

What security measures currently keep you up at night?

When it comes to security, Brandon would like things to become easier, while still giving him the comfort of feeling secure. He believes that, like most people, he would be happy to pay more for something, as long as it is more convenient.

Brandon was very generous with his time, giving us some great insight into the challenges his business faces, along with how he deals with them. If you would like to learn more about the work that Brandon does, you can find him at frankfrankfrank.com