devops技术栈
IBM’s $34B acquisition of Red Hat closed last week, underscoring the huge and growing importance of hybrid cloud infrastructure. My colleague Marek Sadowski has become a subject matter expert in containers, Kubernetes and server-side Swift, although he started out as a full stack developer advocate, a robotics startup founder and an entrepreneur.
IBM以$ 34B的价格收购Red Hat于上周结束，突显了混合云基础架构的巨大且日益重要的意义。 我的同事Marek Sadowski已成为容器，Kubernetes和服务器端Swift的主题专家，尽管他最初是一名全栈开发人员拥护者，机器人初创公司的创始人和企业家。
Marek has 20 years of enterprise consulting experience throughout the USA, Europe, Japan, Middle East and Africa, and he pioneered in research on VR goggles for the virtual reality system to control robots on Mars during his time at NASA. After founding a robotics startup, Marek came to work at IBM. I talked to him about his experience in DevOps advocacy.
Marek在美国，欧洲，日本，中东和非洲拥有20年的企业咨询经验，他在NASA工作期间率先研究了用于虚拟现实系统的VR护目镜，以控制火星上的机器人。 在创建了一家机器人初创公司之后，Marek来到IBM工作。 我和他谈了他在DevOps倡导方面的经验。
目录 (Table of Contents)
- How DevOps advocacy different from API/app advocacy? DevOps倡导与API /应用程序倡导有何不同？
- How do you focus on the DevRel community? 您如何关注DevRel社区？
- What have you changed when moving to DevOps DevRel? 转到DevOps DevRel时，您做了哪些更改？
- How do you get developers to see Swift as server-side? 您如何让开发人员将Swift视为服务器端？
- How did you get into DevRel? 您是如何进入DevRel的？
问：容器是DevRel的重点领域之一。 提倡DevOps技术与提倡API或应用程序有何不同？ (Q: One of your focus areas in DevRel is containers. How is advocating for a DevOps technology different than advocating for an API or application?)
Good question. When working with containers, engineers think more in terms of the plumbing and ideas of DevOps and the ease of expanding your infrastructure footprint. In contrast, when you talk about APIs, you try to make application development the center of gravity for the discussion.
好问题。 在使用容器时，工程师对DevOps的概念和想法以及扩展基础架构覆盖范围的便捷性有更多的考虑。 相反，在谈论API时，您尝试使应用程序开发成为讨论的重心。
When discussing APIs with developers, you talk about how one could -- in a robust way -- consume the API. Let’s take the IBM Watson API as an example: our team will talk about how you can create and run SDKs for developers to consume APIs in their own language, for example, Swift (for mobile) or Java (for enterprise.) You’d look at the consumer of your API and discuss how you can produce the API, protect yourself and do the billing.
在与开发人员讨论API时，您将讨论如何以一种健壮的方式使用该API。 让我们以IBM Watson API为例：我们的团队将讨论如何为开发人员创建和运行SDK，以使用他们自己的语言来使用API，例如Swift(用于移动设备)或Java(用于企业)。查看您的API使用者，并讨论如何制作API，保护自己并进行结算。
Getting back to containers: when discussing container technology, you speak more about plumbing of the cloud. How do you manage containers? Expand them? Manage their workloads? Deliver and test new versions?
再回到集装箱：集装箱讨论技术时，您对云计算的管道多说。 您如何管理容器？ 扩大他们？ 管理他们的工作量？ 交付并测试新版本？
It quickly becomes apparent that these are two separate concepts. Containerization deals with how your backend is working and proper maintenance of your application, which attracts people from a DevOps background. When you talk about APIs, that’s a completely different story. Your thought paradigm changes to the point of view of the consumer: How does the consumer find the API? How can developers consume the API?
很快显而易见，这是两个独立的概念。 容器化处理后端的工作方式以及应用程序的正确维护，这吸引了具有DevOps背景的人们。 当您谈论API时，情况就完全不同了。 您的思维方式转变为消费者的观点：消费者如何找到API？ 开发人员如何使用API？
I speak at conferences on both subjects areas. I’ve found that people who develop applications are more interested in the look and feel and developer experience of the application, whereas with containers it’s more about backend, load balancing, and seeing issues from a system administrator’s perspective.
我在两个主题的会议上都讲话。 我发现开发应用程序的人对应用程序的外观和开发人员体验更感兴趣，而对于容器，则更多地是关于后端，负载平衡以及从系统管理员的角度看问题。
问：很多人熟悉DevRel并专注于软件工程师，但是DevOps完全是一个不同的社区。 您如何关注该社区？ (Q: Many people are familiar with DevRel with a focus on software engineers, but DevOps is a different community entirely. How do you focus on that community?)
There is a division — everybody is interested in new things like Kubernetes and Docker, but not too many will want to perfect their skills to the point that it’s their daily job. So many developers want to know how to spin up a container and a service inside the container, put it in their resume and be done with it. Developers may be interested because it’s fashionable or it’s a buzzword. However, you can find a lot of people who are running services in containers and have specific questions: sysadmins who want to monitor containers and assure security, load balancing, and other aspects of administration. It’s a completely different audience from developers who consume APIs and create a cool web application. They are two different communities, and you have to give each community different content.
有一个部门-每个人都对Kubernetes和Docker之类的新事物感兴趣，但是并没有太多人希望将其技能完善到日常工作。 因此，许多开发人员都想知道如何启动一个容器和容器中的服务，将其放入简历中并完成它。 开发人员可能对此感兴趣，因为它很时尚或流行语。 但是，您会发现很多人正在容器中运行服务并遇到特定问题：想要监视容器并确保安全性，负载平衡和其他管理方面的系统管理员。 与使用API并创建出色的Web应用程序的开发人员完全不同。 他们是两个不同的社区，您必须为每个社区提供不同的内容。
For example, in a hackathon it’s very difficult to create large deployments in containers. It’s an optimization of development and operations more than application coding.
例如，在黑客马拉松中，很难在容器中创建大型部署。 它比应用程序编码更能优化开发和操作。
问：转向DevOps倡导时，您如何改变对DevRel的处理方式？ (Q: How have you had to change your approach to DevRel when moving to DevOps advocacy?)
Previously when I ran workshops focused on application developers, they’ll usually have a few goals: understand our API, consume data from API endpoints and create a simple “Hello World” types of applications. Developers in these workshops will ask questions about high-level ways of architecting applications, e.g. with Watson, in mobile applications or web applications, or a chain of processes.
以前，当我举办针对应用程序开发人员的研讨会时，他们通常会有一些目标：了解我们的API，使用API端点中的数据并创建简单的“ Hello World”类型的应用程序。 这些讲习班的开发人员将询问有关构建应用程序的高级方法的问题，例如在移动应用程序或Web应用程序或流程链中使用Watson的方法。
On the contrary, when I speak about DevOps and containers, developers in the audience want to spin up the services, see how they scale up and scale down, investigate how the services behaving when something is failing and how to ameliorate security issues. It’s a completely different approach. They are not interested in building something new, they want to perfect their approach to deployment.
相反，当我谈论DevOps和容器时，听众中的开发人员希望启动服务，了解它们如何按比例缩放和按比例缩小，调查出现故障时服务的行为方式以及如何改善安全性问题。 这是完全不同的方法。 他们对构建新事物不感兴趣，他们希望完善其部署方法。
An analogy I can give to people new to this field: it’s like inviting a painter and a plumber to a party. They both do similar things, yet the painter wants to make a painting that you can hang on the wall, and the plumber will rarely speak about the type of piping he’s using inside your walls. Both are doing something in your house, but the painter is thinking about the people they will attract and the paint (our APIs) to ensure a pleasant viewing experience, while the plumber just wants to get the job done and never touch it again. The plumbers want to make changes as rarely as possible and focus on stability, the painter wants to create more new paintings. They have different approaches based on their different goals.
我可以给这个领域的新手一个比喻：就像邀请画家和水管工参加一个聚会。 他们俩都做类似的事情，但是画家想要画一幅可以挂在墙上的画，水管工很少谈论他在墙上使用的管道的类型。 两者都在您的房子里做某事，但是画家正在考虑他们将吸引的人和油漆(我们的API)以确保获得愉悦的观看体验，而水管工只是想把工作做好而不用再碰。 水管工希望尽可能少地进行更改，并专注于稳定性，画家希望创建更多新的绘画。 他们基于不同的目标有不同的方法。
问：您还会在Swift上进行演讲，特别是在服务器端。 大多数人都从iOS开发方面了解Swift，但是为什么它在服务器上有用呢？ 您如何使开发人员将其视为服务器语言？ (Q: You also give talks on Swift, specifically on the server side. Most people know Swift from the iOS development side, but why is it useful on the server? How do you get developers to think of it as a server language?)
Server-side Swift is a relatively new development. I compare the current state of server-side Swift to where Java was twenty-four years ago. In 1996 I started writing a server-side application using Java -- it was a novel concept at that time! The same thing is happening now with Swift, as developers are moving the Swift language to the server. There are a lot of reasons why; one of the simplest is that you write in the same language on the server as you do for your mobile app, and in that way you can use the same data constructs, thought processes and personnel resources on both systems. You don’t need different systems or frameworks to talk to the database or the cloud.
服务器端Swift是一个相对较新的开发。 我将服务器端Swift的当前状态与Java二十四年前的状态进行了比较。 1996年，我开始使用Java编写服务器端应用程序-当时这是一个新颖的概念！ 现在，随着开发人员将Swift语言移至服务器，Swift也发生了同样的事情。 原因有很多； 最简单的方法之一是，您在服务器上用与移动应用程序相同的语言编写内容，从而可以在两个系统上使用相同的数据结构，思维过程和人力资源。 您不需要其他系统或框架即可与数据库或云进行通信。
Every mobile app nowadays asks you to connect to the internet for AI, messaging and social media. Even simple games allow you to exchange information or have a conversation with people all over the world. If your app and back-end are written in one language like Swift, it makes these data exchanges simple and transparent.
如今，每个移动应用程序都要求您连接到AI，消息传递和社交媒体的互联网。 即使是简单的游戏，您也可以与世界各地的人交流信息或进行对话。 如果您的应用程序和后端是用Swift这样的一种语言编写的，它将使这些数据交换变得简单而透明。
Some people are saying Swift is a fashionable language to learn. Since you have the option to write apps in Java or JavaScript, you can also write them in Swift. Swift has now been open-sourced by Apple, similar to the way Sun opened up Java. You can now write applications in the cloud or on any platform. For example, OpenWhisk allows you to write event-based Swift functions in the cloud without any DevOps code.
有人说Swift是一种流行的学习语言 。 由于可以选择用Java或JavaScript编写应用程序，因此也可以用Swift编写应用程序。 Swift现在已由Apple开源，类似于Sun开放Java的方式。 现在，您可以在云或任何平台上编写应用程序。 例如，OpenWhisk允许您在云中编写基于事件的Swift函数，而无需任何DevOps代码。
With Swift, developers are attracted to the beauty of the language and the ability to write one language from mobile to cloud to make your application better and easier to maintain. You can enjoy writing in your language of choice and expand the capabilities of the environment you love. If you are an iOS developer, maybe you can become a full-stack developer, and developers love the story that they can become something more and participate in the full stack development process.
借助Swift，开发人员会被语言的魅力以及能够将一种语言从移动设备编写到云中而吸引，从而使您的应用程序更好，更易于维护。 您可以使用自己喜欢的语言来写作，并扩展自己喜欢的环境的功能。 如果您是iOS开发人员，也许您可以成为一名全栈开发人员，并且开发人员喜欢他们可以成为更多人并参与全栈开发过程的故事。
问：您是如何建立开发者关系的？ (Q: How did you get into developer relations?)
I had just come to the United States from Poland as the founder of a startup, and the purpose of the move was to expand my company. They say that 99% of startups don’t succeed right away, and founders often need to bootstrap while in an existing job. I was told that working in the cloud is the key factor in a lot of industries, but I had little exposure to those technologies. On the other hand, I had built up skills talking to investors, and as an entrepreneur, I was able to understand what was important to startups. I also had a robust background in Java development and different IT technologies — I had a career as an architect supporting banks and other enterprises EMEA as a Java professional, demonstrating systems to customers.
我刚从波兰来到美国，是一家初创公司的创始人，此举的目的是扩大我的公司。 他们说，有99％的初创公司不会立即成功，因此创始人经常需要在现有工作中进行引导。 有人告诉我，在许多行业中，在云中工作是关键因素，但是我很少接触这些技术。 另一方面，我已经建立了与投资者交流的技能，作为一名企业家，我能够理解对于初创企业来说重要的是什么。 我在Java开发和各种IT技术方面也拥有扎实的背景-我曾作为一名架构师来支持银行和其他企业EMEA(欧洲，中东和非洲)，是一名Java专业人士，向客户展示了系统。
There was an opening for a mobile-first developer advocate, and despite having no mobile or cloud experience, I convinced the interviewer that I was the perfect candidate due to my ease of speaking with developers and presenting technical subjects in an accessible manner. I enjoy explaining complex topics in a simple way through demos and example projects.
有一个以移动为先的开发人员倡导者的开放空间，尽管没有移动或云经验，但我使采访者确信我是最理想的人选，因为我易于与开发人员交流并以易于访问的方式介绍技术主题。 我喜欢通过演示和示例项目以简单的方式解释复杂的主题。
My hiring manager asked me to build a small mobile app as an employment test, which connected to IBM Cloud to exchange information between the user and a backend. I enjoyed the task and found I was good at it! After two years, I migrated to more cloud technologies and more and more IBM APIs. Eventually I started to find interest in Kubernetes and containers, and I realized containers are a field with amazing growth potential.
我的招聘经理要求我构建一个小型移动应用程序作为一项招聘测试，该应用程序连接到IBM Cloud，以在用户和后端之间交换信息。 我喜欢这项任务，发现自己很擅长！ 两年后，我迁移到了更多的云技术和越来越多的IBM API。 最终，我开始对Kubernetes和容器感兴趣，并意识到容器是一个具有惊人增长潜力的领域。
I must say, the thing that attracted me the most to DevRel was the opportunity to learn and convey new technologies to developers out there, and use my talent for explaining complex things in a straightforward manner.
我必须说，DevRel最吸引我的是机会，以学习和向那里的开发人员介绍新技术，并利用我的才能以直接的方式解释复杂的事物。
下一步： ( Next Steps:)
See Marek speak at an upcoming IBM Developer SF Meetup
参见Marek在即将举行的IBM Developer SF Meetup上的演讲
翻译自: https://www.freecodecamp.org/news/devrel-down-the-stack-containers-kubernetes-and-devops-engineers/
devops技术栈
扫一扫
1140
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
