Category: Innovation

Pulling the Strings – Podcast with Puppet

Virtualization & Kubernetes: Why another abstraction?

 

EPISODE NOTES

Martez Reed and Bruno Andrade of Shipa talk about Kubernetes, virtualization, and how to avoid vendor lock-in.

I had virtualization… Then you gave me Kubernetes on top of virtualization. I thought Kubernetes was supposed to be the answer, and now you’re telling me it’s not the answer and I need something else on top of Kubernetes?! The conundrum is solved on this episode of Pulling the Strings with Martez Reed and Bruno Andrade.

Learn More

  • The Puppet Kubernetes module
  • Watch how you can install and bootstrap a Kubernetes cluster with the Puppet Kubernetes module.

SHOW CONTRIBUTORS
Demetrius Malbrough
Bruno Andrade
Martez Reed
 
 
 
Click on the image to Play the Podcast

Techworld with Nana: DevOps Tool of the Month

Run mission-critical applications on Kubernetes

DevOps tool of the month is a series, where each month I will introduce one new useful DevOps tool in 2021

For March I chose: Shipa – Shipa’s cloud native application management framework makes working with Kubernetes for developers extremely easy.

What problems does Shipa solve?

Shipa solves problems both for developers and for K8s administrators.

Developer problems:

Let’s say in your project you decided you will use Kubernetes to run your application. In such cases, developers will need to learn Kubernetes, like K8s YAML configuration files, K8s components, kubectl etc.

As a result developers take most of the time away from actually programming and instead spend it on learning K8s and trying to configure the application to run on K8s.

In addition, they may misconfigure or deploy their application with security issues simply because they don’t know the security best practices in Kubernetes.

Continue reading the article here or

Watch the video below with Nana presenting and demo’ing Shipa.

3 Things You Should Be Doing in Cloud Native in 2021

As we wrap up the first quarter of 2021, we wanted to talk about things we should be doing as part of a cloud native strategy for the remaining 3/4 of the year. Moving from traditional monolithic. architectures to a modern microservices approach has many benefits, but still has the greater majority of us baffled in terms of tapping into its full potential. 

In this episode of Coffee & Containers, Jim Shilts, Developer Advocate at Shipa chats with Angel Rivera, Developer Advocate at CircleCI, and Vivek Pandy, VP of Engineering at Shipa about helping organizations get ahead of the curve by considering these topics:

  1. Anticipating the next big hill in CICD
  2. Application Policy Management 
  3. Reducing the Human Element (again)
cloud native strategies

3 Things You Should Be Doing in Cloud Native in 2021

Recorded March 17, 2021

1. Anticipating the Next Big Hill in CI/CD

The first cloud native strategy has to do with anticipating and preparing for the next CI/CD challenge. Many traditional CI/CD solutions or approaches were developed with traditional or legacy application architectures in mind, and many of those approaches may be well suited for a monolithic application deployment, but may not be well suited for Kubernetes or Cloud Native environments. What hills are approaching in cloud native CI/CD, and how can we be prepared?

2. Application Policy Management

Cloud native strategy number two focuses on building a trusted and secure process. From development to deployment, we need to ensure that all mandates and policies are followed and that no steps in the process introduce new vulnerabilities, and just as importantly, that no steps are skipped. This is particularly true in highly regulated industries such as banking, but with all of the data everyone is storing these days, penalties for a breach, loss in revenue/customer confidence, etc, this really just as important for everyone building and deploying software. What strategies are there for tackling this challenge?

3. Reducing the Human Element (again)

The final cloud native strategy brings us back to the days before any of us were saying “DevOps.” If we go all the way back to the beginning of CI and build automation, eliminating the human error aspect was arguably the biggest win. Speed was an added bonus, and speed really just helped to shift the bottleneck a little more to the right. In cloud native, we are seeing history repeat itself with a lot of manual effort going into Kubernetes deployments. Teams are approaching Kubernetes deployments with Helm, YAML, scripting, etc which all take a high level of manual effort to maintain. What should we be doing to reduce the risk of a manual approach, and how do we ultimately get to a trusted and repeatable process where the promises of speed in Kubernetes are realized?

Watch the full video discussion here:

Deploying applications to Kubernetes from your CI pipeline with Shipa and CircleCI

Deploying Applications to Kubernetes

A tech tutorial with Shipa and CircleCI

Kubernetes can bring a wide collection of advantages to a development organization, but efficiently deploying applications to Kubernetes is something many organizations are still working to perfect.

Properly using Kubernetes can significantly improve productivity, empower you to better utilize your cloud spend, and improve application stability and reliability. On the flip side, if you are not properly leveraging Kubernetes, your would-be benefits become drawbacks. As a developer, this can become incredibly frustrating when your focus is on delivering quality code fast.

The learning curve and management of the object-centric application architecture, scripting, integrations into multiple CI systems and pipelines, and managing infrastructure can all make you less productive. According to a survey conducted by Tidelift and The New Stack, just 32% of a developer’s time is spent writing new code or improving existing code. The other 68% is spent in meetings, code maintenance, testing, security issues, and more.

What if developers could take full advantage of the benefits of Kubernetes while avoiding its pitfalls? In this tutorial, we will show how CircleCI and Shipa together can empower teams to get the best possible performance out of deploying applications to Kubernetes. How does it work? CircleCI maximizes speed with customizable pipelines, while Shipa simplifies Kubernetes. The combination gives developers more time to do what they do best: develop quality software quickly, without changing the way they work. Your platform engineering team can manage, secure, and deliver a powerful Kubernetes platform that benefits the entire development organization.

Head to CircleCI for the full tutorial

Start deploying applications to Kubernetes today with Shipa and CircleCI!

Prerequisites

For this example, we assume you have:

deploying applications to kubernetes

Shifting Complexities in DevOps

In this episode of ShipTalk, Jim Shilts, Developer Advocate at Shipa chats with Ravi Lachhman, Evangelist at Harness on the “Shifting Complexities in DevOps.”

Jim has been working on solving engineering efficiency problems for over 20 years, working at firms such as Build Forge and Electric Cloud, pre-dating the inception of Hudson/Jenkins. Jim walks through his experience and how complexity and bottlenecks have shifted around in the decades gone by, and whats in store for the future. 

Read the transcript

“Shifting Complexities in DevOps”

Ravi Lachhman 00:06
Hey, everybody! Welcome back to another episode of ShipTalk. I’m really excited to be here with Jim Shilts, who’s a developer advocate. So Jim’s a developer advocate at a cloud native firm called Shipa— but Jim, for the folks who don’t know you, why don’t you tell us a little bit about yourself?

Jim Shilts 00:25
Yeah, thanks for having me on your podcast here today. I’m Jim Shilts, as you said, I’ve been in this space for quite a while; I think it was 2003 when I got into this space. It was before the phrase DevOps even existed— about six years before it did. And about six years ago, I started a group called North American DevOps group, also known as NADOG. That group is really all about getting together [and] learning from each other. We started here locally in Southern California, and it quickly grew into other cities. It used to be the SoCal DevOps Group, and then we had to change the name to NADOG; then we started doing events in Europe a couple of years ago, so rather than change the name again, we’re just known as EuroDOG there and NADOG here.

Now with COVID, you know, we’re doing all these things online— but still, the spirit is the same. It’s about getting together, talking about our industry, learning from each other and doing it in a fun and casual environment. So you can actually make some real connections in this space.

Microservices in the Financial Industry

In this episode of Coffee & Containers, Jim Shilts speaks with Shipa‘s Bruno Andrade and Fiserv‘s Ken Owens about microservices in financial organizations.

The topics covered include:

  • What is the role of microservices and cloud-native in the financial sector?
  • Where on the scale in the adoption do you think financial services companies really are?
  • How do we manage the culture shift in a microservices transformation?

Watch the full video:

Excerpts:

What is the role of cloud-native and microservices in financial organizations?

Ken Owens

Ken Owens

Vice President Cyber Cloud Security Engineering, Fiserv

A lot of our use cases with credit card transactions and with securing transactions, the closer we can get to merchants, to banks, and to our customers, the better we can secure those transactions, the better we can get data quickly.

There’s a lot of interesting use cases in financial services around edge computing, around server-less computing, and around Kubernetes usage. And I think in the financial services markets, there’s a lot of interest in containers and containerization. I know the adoption is typically slower in financial services. A lot of financial services companies are older, more established companies that have a lot of compliance and regulatory pressures on them to keep different types of security, different types of data treated differently than we would, movies or books or whatever you might be purchasing.

The information used to purchase all of that is a little bit more critical than the name of a movie that you’re watching or what food you’re ordering. So there’s a lot less risk-taking going on in the financial services market. A lot of what I mentioned with the transaction processing and getting closer to the edge is probably the number one area that financial services are looking at, moving into Kubernetes and the cloud, for sure.

Where on the scale is the adoption of microservices in financial organizations?

Bruno Andrade

Bruno Andrade

Founder and CEO, Shipa

A lot of the discussions that we have with the financial services firms out there today as they start the journey is that they understand what Kubernetes and microservices are and they have started doing the first few migration. They started with satellite projects, and as they start rolling out Kubernetes across the the whole company, we see a lot of these folks having trouble. There’s a lack of workflow, especially  between the roles of the developers versus the DevOps/Platform Engineering team, the infrastructure team and the security team. There is no centralized workflow there. There are a lot of impacts, especially as the organization tries to scale up across multiple clusters or maybe different clouds for different applications and then different teams responsible for them.

And I see a lot of financial services trying different approaches and different tools as they try to fix the problem, but it’s still an open problem, especially when you talk about the developer experience going down, being a heavily regulated industry, enforcing policies and security across a wide range of clusters and teams. From my perspective that that’s where I see the conversation. Microservices works for us, but now it’s time for us to structure the process, to make sure that we can append that growth.

Share on email
Email
Share on twitter
Twitter
Share on linkedin
LinkedIn

About the Speakers

Ken Owens
Vice President Cyber Cloud Security Engineering
Ken is a technical executive with 20+ years of experience in architecture, analysis, design, research, and implementation of cloud-native patterns, data center, and cloud computing infrastructures consisting of SOA software design, virtualization, server, network, security, storage, automation, management layers, and deployment methodologies. Experience in system engineering functions, such as system architecture development, system requirements synthesis, performance modeling, behavior modeling, feasibility analysis, and validation of multi-layered communication systems. He is currently Vice President of Cloud Cyber Security at Fiserv.

Bruno Andrade
CEO & Founder, Shipa Corp
Bruno has led distributed systems design and implementation at enterprises across different industries, defining methodologies, concepts, and architecture. He has dedicated the last few years to working on the Cloud Native space, helping companies through a successful journey.

Resources:

Get Started With Shipa

Application Development in the Modern World

Application Development in the Modern World

In this episode of Coffee & Containers, Jim Shilts speaks with Shipa‘s Bruno Andrade,  VMware Tanzu‘s Gautham Pallapa, and IBM Cloud‘s Jason McGee McGee.

The topics covered include:

  • The current state and key challenges surrounding Kubernetes
  • Selecting from and integrating a diverse set of tools
  • How do we stay relevant in a rapidly evolving space?

Watch the full video:

Excerpts:

The Current State and Key Challenges Surrounding Kubernetes

Jason McGee,

Jason McGee,

IBM Fellow, VP and CTO, IBM Cloud Platform

I think we are kind of in a scale and industrialization phase for a lot of companies, you know,  we’ve done the first projects. Many organizations have containerized environments, they’re running Kubernetes, they’re doing cognitive things. Maybe they did that in small pockets or with kind of leading edge teams.

And what they’re really trying to figure out now is how do we do this at scale across the organization? How do we get all of the projects moved over? How do we deal with the complexities of existing applications? How do we deal with maybe hybrid architectures where I need some things in public clouds and some things on premise. We’re trying to figure out how to do regulation compliance and move sensitive workloads. It’s really about taking the ideas that this community of people has been talking about for the last few years, and drive it into mainstream adoption. And I think with that comes some interesting challenges, right? I think there’s a skills challenge for a lot of organizations where they don’t have enough people who really understand the technology. I think later we’ll talk about the diversity of technology in that space.

It’s pretty overwhelming for many people. So, how do you build skills? I also think that there’s an interesting set of activities going on around how developers interact. I’ve spent most of my career in the app platform space. I originally was an app server person at IBM. So I’ve been thinking about app development platforms for a long time. And and one of the things I think is really unique right now is that with Kubernetes, the entire industry has basically agreed on a common platform. I don’t know that that’s ever happened. Even back in the app server days, we at least had java and .net. We had two platforms, but pretty much everyone is agreed, both in the vendor community and in the customer, base that Kubernetes is the platform to go forward on.

Partly because Kubernetes is so flexible, but if you even look at it from a developer perspective, that flexibility comes with complexity, and a lot of concepts, and a lot of knobs to turn, and a lot of ways to solve problems. And so I think the challenge now is, how does the average developer consume a cloud native platform? Are there abstractions, like some of the stuff we’re doing in K native, for example, as a project to build abstractions, like how do we connect it to the DevOps process in the right ways so that, it’s easier to consume? I think we’re in this scale industrialized phase, and I think we have to really think about it that way and think about how the broad mass of the development community can be successful.

Selecting from and Integrating a Diverse Set of Tools

Gautham Pallapa, Ph.D.

Gautham Pallapa, Ph.D.

Global CTO, VMware Tanzu

So if you’ve seen the CNCF landscape [https://landscape.cncf.io], it’s pretty intimidating. I think as of last count, there’s more than 1,500 different projects running and very few of them have actually proved themselves. Basically we want to focus on what’s high value activity. We want the developers to create ideas, to design, to create those products that are going to bring immense delight to customers.

Even from the pivotal days where we used to have crypto Cloud Foundry, the goal was to have the developers focus on what they do best and then abstract that complexity. At the same time, have the operators focus on what they do best–the data activity, the stability, and the reliability of the platform. So taking the entire landscape, especially if you’re a CIO or someone who’s tasked with creating the perfect secure software supply chain for your organization, that’s going to transform the org and drive your organizational culture through technology. It’s pretty intimidating as it stands today, but it boils down to a couple of things.

The first thing you want to do is you want to have some kind of a modern dev framework. You want to provide the flexibility to the developers. To have a good framework in any kind of language, a good CI system, data pipeline system, relational DBs, you want to provide them and enable them with the tools and databases and services. As part of that, you want to provide some kind of a Kubernetes dial tone or a framework so that they are building containerized applications and they don’t have to worry about the complexity of all of this. The next thing is integrating that into the CI system so that when the code is checked in, either to GitOps process or DevSecOps process, you’ll have it go into some automated container packaging system where it’s validated, it’s scanned, you already are patching, you know, the vulnerabilities and you can reproduce, and then you store them in one of your container registry systems.

How do we stay relevant in a rapidly evolving space?

Bruno Andrade

Bruno Andrade

Founder and CEO, Shipa Corp

We at Shipa, we chose to be opinionated where we as a team believed opinionated approaches add value, and to be non-opinionated where that adds value as well. We decided to build ship as a framework for your application management on top of Kubernetes; it doesn’t really matter where you’re running, right? If even if you’re running on IKS from IBM, OKE from Oracle, GKE from Google AKS, etc. So if you want to use Istio as, as your ingress controller, if you want to use Traefik or Prometheus, for example, we allow you to connect these to Shipa and use the best of breed for your use case in the underlying infrastructure based on your corporate requirements or your application requirements.

Then, start establishing some boundaries as you start moving toward platform operationalization. That way that you can define: every application that gets deployed here, gets this set of controls and guard rails, such as set of security scans, this set of network policies apply, this set of teams and connections to external services, etc. So here you start being a bit more opinionated, but we chose to allow you to change and move the underlying infrastructure as you need, and be non-opinionated there in a way that if you want to swap your Kubernetes clusters or diversions, you can underneath Shipa in a way that it doesn’t impact the application layer and your developers and the operationalization boundaries that you created.

We chose to drive the strategy so we’re not one or two steps behind when Kubernetes comes out with a new version, a new functionality, etc. We chose to allow you to change the components that you want to underneath, but without impacting the operational position controls that you defined for your platform and your developers.

About the Speakers

Bruno Andrade
CEO & Founder, Shipa Corp
Bruno has led distributed systems design and implementation at enterprises across different industries, defining methodologies, concepts and architecture and has dedicated the last few years to working on the Cloud Native space helping companies through a successful journey.

Jason McGee
IBM Fellow, VP and CTO, IBM Cloud Platform
Jason is responsible for the IBM Cloud’s platform services, including OpenShift, Kubernetes, Serverless Functions, Satellite, Code Engine, Cloud Foundry, Logging, Monitoring, Container Registry, Schematics, Terraform and Activity Tracker. Jason is also responsible for the technical strategy and architecture for all of IBM’s Cloud Developer Platform (PaaS). Previously Jason has served as CTO of Cloud Foundation Services, Chief Architect of PureApplication System, WebSphere Extended Deployment, WebSphere sMash, and WebSphere Application Server on distributed platforms.

Gautham Pallapa
Global CTO, VMware Tanzu
Gautham works as a trusted advisor with Global 2000 enterprise customers in transforming their strategy, processes, technologies, culture, and people to achieve their objectives and business outcomes. His mantra is “Transform with Empathy” and has successfully led several business transformations and cloud modernization efforts in various industry verticals. Gautham is an agile coach, a Lean Six Sigma Black Belt, a SAFe Agilist, and an Ambassador for the DevOps Institute. He writes/talks/works on transformation, elevating humans, helping underprivileged people, and giving back to the community.

Leap-Frog Over your Kubernetes Obstacles

Fearless Delivery with an End-to-End DevOps Platform

“Leap-Frog Over your Kubernetes Obstacles”

In this episode of Coffee & Containers, Bruno Andrade, Founder/CEO @ Shipa, and Melissa McKay, Developer Advocate @ JFrog, discuss some specific Kubernetes related obstacles:

  • Artifact Repositories in CloudNative
  • Liquid Software
  • Post-deployment application management
Bruno Andrade and Melissa McKay

Excerpts from the discussion:

Managing repos in

MELISSA: I think the best thing I can point out there is just, there are so many more binaries,  libraries’ dependencies every day than ever before. So it’s, it’s becoming a thing, it’s becoming more difficult to manage. It’s like buying a new pair of shoes every day, and you got to stuff them all in the same closet, you know? And then you got to find the pair you wanted to wear that day.

BRUNO: I like to use the pizza analogy. A lot of people really get stuck on trying to put together all of the ingredients, right? Then, the pepperoni, making the dough, et. In terms of development, those are the objects, right? So you have to put in your image, then your rules, your deployment says they’re clustered, then you add a security scan, and you’re trying to tie all of this together. If you’re doing this for a small service or a small number of services, or a small team, you may get away with it. But as you scale, and we work with companies that are deploying a hundred, 200, or 500 services across thousands of developers, this is just a nightmare. So if you can have an integrated process that basically brings your ingredients together for you automatically and allows you to focus on eating the pizza, which is the part I like, that’s just a win-win situation, right?

frog and Shipa for kubernetes

Liquid Software

MELISSA: We often see continuous delivery pipelines. That means everything is automated, but there is that one extra step that somebody has to push that button to actually deploy to an environment. We get stuck at continuous integration where we have that setup, we’ve got our builds automated, our unit testing automated, but then what do we do? I see some pretty strong use case scenarios here, especially for staging environments and testing environments, on top of your production environment to make this a little bit easier for different teams to get their software through these quality gates and out the door faster.

BRUNO: I’m basically storing that image into Artifactory. And as soon as it is done, I’m applying to Shipa. So as a developer, I don’t have to learn what Kubernetes is. I don’t have to see anything, GKE. I don’t need to know what the deployment versions and API versions are. I don’t have to learn or interface with any of that. I get my application, and I deploy my application pointing to the pool that my DevOps person gave to me. And that’s it, I’m just applying my image, or I’m deploying my application through the CI pipeline. I can do that directly from Git, and I can see the logs. The steps and the status of each. 

Shipa for Kubernetes

Post-Deployment

MELISSA: My first experiences on a DevOps team were pretty eye-opening. I had no idea the acrobats that operations was taking to deploy some of the apps that we had. This is when I first started getting interested in containers. I know that that’s another thing that can be obstructed away from developers, but that was something that I was really curious about and got into. So I learned how to build containers efficiently so that they can be deployed more efficiently. But some of the things that happened in my experience was, months after an app was deployed, all of a sudden somebody sends an email, “Hey, these containers are restarting all the time.” Some of our tools that we use to keep our apps up and running are causing the problem.

BRUNO: We have integrations into different incident management tools, such as Slack, where if the application is getting restarted, or if  a deployment fails or succeeds, you can set up alerts on Slack, PagerDuty, and all of your other incident management tools where you can alert the developer and so on. The better you can implement the controls and guard-rails and just leverage the infrastructure, the more you can focus on the app and the controls around it and not be bogged down by the infrastructure.

Watch the full webcast here:

Leap-frog over your kubernetes obstacles with JFrog and Shipa

Resources:

A Vision of Liquid Software Whitepaper: https://jfrog.com/whitepaper/a-vision-of-liquid-software/

JFrog Artifactory – Start for Free: https://jfrog.com/artifactory/start-free/

PodInfo application – https://github.com/brunoa19/podinfo

Melissa McKay is a long time developer turned international speaker and is currently a Developer Advocate for JFrog, Inc., with a mission to improve the developer experience of DevOps methodologies. Her background and experience as a software engineer spans a slew of languages, technologies, and tools used in the development and operation of enterprise products and services. She is a mom, software engineer, Java geek, huge fan of UNconferences, and is always on the lookout for ways to grow and learn. She has a passion for teaching, sharing, and inspiring fellow practitioners and you are more than likely to run into her in the conference circuit. 

Bruno Andrade is CEO and Founder of Shipa. He has led distributed systems design and implementation at enterprises across different industries, defining methodologies, concepts and architecture and has dedicated the last few years to working on the Cloud Native space helping companies through a successful journey.

Try Shipa Today!

Full lifecycle application-centric framework for Kubernetes so everyone can focus on applications, and not Kubernetes obstacles
Share on email
Email
Share on twitter
Twitter
Share on linkedin
LinkedIn

The Future of Kubernetes on DevOps Radio

DevOps Radio Episode 90: Shipa's Bruno Andrade on the Future of Kubernetes

In this episode of DevOps Radio, Shipa’s CEO and Founder Bruno Andrade joins host Brian Dawson to discuss his thoughts on the future of Kubernetes.

DevOps Radio is a CloudBees-sponsored podcast series. Hosting experts from around the industry, the show dives into what it takes to successfully develop, deliver and deploy software in today’s ever-changing business environment. From DevOps to Docker, each episode features real-world insights and a few stories, tips, industry scoop and more. Our goal is to offer up a variety of experts, but you’ll hear from CloudBees own experts from time-to-time, too.

Shipa (https://www.shipa.io), is the full lifecycle application-centric framework for Kubernetes and multi-cluster portability. Shipa creates the guardrails, compliance and controls for your Kubernetes and  applications, while at the same time helping to eliminate all the yaml-files, helm charts and custom scrips that are most likely starting to pile up and slowing things down for your developers.

"I’m an engineer. I love sitting down and dealing with cool, brand new tech and testing stuff. But how much time do you actually spend on that rather than what it actually needs to deliver?"

Bruno Andrade, CEO, Shipa Corp

Full transcript and more episodes of DevOps Radio HERE.

Host Brian Dawson is a DevOps evangelist and practitioner with a focus on agile, continuous integration (CI), continuous delivery (CD) and DevOps practices. He has over 25 years as a software professional in multiple domains including quality assurance, engineering and management, with a focus on optimization of software development. Brian has led an agile transformation consulting practice and helped many organizations implement CI, CD and DevOps.

Guest Bruno Andrade is CEO and Founder of Shipa. He has led distributed systems design and implementation at enterprises across different industries, defining methodologies, concepts and architecture and has dedicated the last few years to working on the Cloud Native space helping companies through a successful journey.

Try Shipa Today

Full lifecycle application-centric framework for Kubernetes so everyone can focus on applications

Kelsey Hightower and Shipa for Kubernetes: A Fireside Chat

Coffee and Containers

“Shipa for Kubernetes: Fireside Chat with Kelsey Hightower”

On October 22, 2020, Shipa launched a new web series called “Coffee & Containers” with our first guests, Kelsey Hightower and Bruno Andrade. C&C was conceived as a place for practitioners and IT leaders to learn and collaborate on all things microservices, cloud-native, containers, Kubernetes, etc.

We were very proud to launch this series with Kelsey Hightower, Thought Leader and Developer Advocate at Google Cloud Platform, and Bruno Andrade, Founder, and CEO of Shipa.io. The topic of the conversation was focused on the current state of Kubernetes and concluded with an “unboxing” and Kelsey’s live/unfiltered impressions on the Shipa application management framework for Kubernetes.

Key topics of the conversation included:

  • Application Context
  • Integrations into Pipelines
  • Application Management Workflows

Here are some highlights from that conversation:

47% of the attendees polled responded that the learning curve and management of an object centric application architecture was the most challenging part of moving to a Kubernetes architecture.

KELSEY HIGHTOWER: “I think this also speaks to another thing that learning is hard in general, I think in terms of new things. When I learned Linux for the first time, I think I’m still about 15, 16 years in, still learning Linux, the system calls, the shell, the various utilities, and how to piece things together. So, I don’t think you’re ever going to stop learning. I don’t think it’ll be easy. But specifically, the question here, which is in managing all these objects, right, so what does that mean? I think a lot of times, at least me personally, we come from a world where you automate things you understand, or you use scripting languages that let you do pretty much anything. If this, do that, and then you can navigate through there.”

“it’s going to be a learning curve because Kubernetes will force you to learn its type of structure before you can do anything, but that’s only at the base level. I’m hoping today, and we can dig into how tools like Shipa that rightfully so sit above that statically-typed language of Kubernetes to provide these workflows, the things that people say should be much easier. I believe, tools above it should be doing that work.”

BRUNO ANDRADE: “I think it’s important for you to understand what is happening in and how the objects are interacting and how this relates to your application itself. When we started thinking about building it with Shipa for Kubernetes, we interviewed a lot of users and realized that was a big issue for them. A lot of them were even asking, “What is an application on Kubernetes? Because after I deploy my objects, basically, they become these objects in the cluster, and they have no relation.”

We allow the users to deploy without having to create these objects manually, but at the same time, we give you the visibility.”

Shipa for Kubernetes multi-cloud portability
KELSEY HIGHTOWER: “Hey, isn’t this like what Openshift is doing? What’s different?”

BRUNO ANDRADEGreat question…You have to use OpenShift clusters on IBM or on whatever clouds they are supporting right now. It becomes costly from different points, either from licensing calls or from you having to use a specific cluster. I hear that upgrades are really troublesome, and so on. So, you’re locked into that. The other thing is how they operate from an application level, there’s a lot of rip and replace that you have to do, such as when it comes to your CI pipeline and CD.

With Shipa, we’re plugging into your existing CI/CD pipeline. In the post-management of the apps, we’re backing a lot of the object management perspective. While with Shipa, it’s giving you the application context view through and through. So, at least the way I put them is it’s your traditional past. If we’re thinking about building a scalable infrastructure and allow you to have control over everything, it may be a challenging option for you.

KELSEY HIGHTOWERI guess the case is if I understand, right, can I just connect Shipa to Openshift since Openshift has Kubernetes in there? Can I just literally connect Openshift and just use the Kubernetes interfaces, just like I would GKE if I prefer this better?

BRUNO ANDRADEYeah, and then we’ve seen users actually going down that route, exactly because of that. They have some Kubernetes in house. They started in the Openshift. They saw that they wanted more flexibility. So, layering over Shipa for Kubernetes on top of Openshift is the option and the route that they’re going in that case.

Try Shipa Today!

Full lifecycle application-centric framework for Kubernetes so everyone can focus on applications
Share on email
Email
Share on twitter
Twitter
Share on linkedin
LinkedIn