devopsy.kinsta.cloud

Tag: environment

  • Tools for Sustainability in Cloud Computing

    Tools for Sustainability in Cloud Computing

    Cloud computing is a primary driver of modern technological advancements. However, as cloud services adoption continues to soar, so does a concern for their environmental impact. The further expansion of cloud infrastructure will demand more energy, which means the need for sustainable solutions has never been more acute.

    Due to their scale, cloud vendors operating large data centers have a greater impact on minimizing the IT’s industry overall carbon footprint than do smaller on-premises deployments. In this article, we highlight the main benefits of migrating business operations to the large-scale cloud providers known for their established sustainable practices, and point to useful resources.

    Follow the Leaders

    Major cloud platforms, including Google Cloud Platform, Amazon Web Services and Microsoft Azure, have pledged to achieve net-zero carbon emissions in their data centers by 2030. These platforms are well-positioned to lead the adoption of sustainability principles in cloud engineering due to their reputation and global reach.

    Microsoft’s study on the carbon benefits of cloud computing showed that an enterprise could reduce its carbon footprint by up to 98% by migrating to Microsoft Cloud, compared to running its IT operations in the on-premises data center.

    As for Google Cloud, all of its cloud products are carbon neutral. Google achieves this by purchasing renewable energy to reduce the carbon footprint from operations performed on its infrastructure, as well as by using high-quality carbon credits to compensate for its remaining carbon emissions.

    By moving your operations to the cloud and focusing on developing cloud-based applications, you can contribute to sustainable business practices and overall carbon footprint reduction.

    Increase Energy Efficiency

    Public cloud platforms rely on large-scale data centers with advanced infrastructure technologies. That allows them to reduce electricity consumption for overhead tasks such as lighting, cooling, and power conditioning. For example, according to Google’s environmental report, its data centers consume half the energy needed to power an average on-site data center.

    Energy efficiency is also driven by higher server utilization rates and the ability to manage workloads flexibly. These are the main factors that allowed AWS to make its data centers 3.6 times more energy efficient than a median data center run by a U.S. company.

    Additionally, the innovative approach applied to server architecture design in large data centers enables cloud service providers to develop custom hardware optimized for their customers’ workloads.

    Big Names are Committed to Sustainable Software Development Practices

    Another environmental benefit of running IT operations in the cloud is that public cloud platforms are committed to sustainable software engineering – and they want to make it feasible for anyone who uses their platforms.

    Green (or sustainable) software starts at the design phase, considering carbon emissions as a project requirement. According to the Green Software Foundation, sustainable software applications are carbon efficient (can run on fewer machines and resources), energy efficient (require less energy to perform the same tasks), carbon aware (prioritize renewable energy sources as a power source) and hardware efficient (use less hardware).

    IT operational efficiency is a fundamental of sustainable software engineering. Since cloud service providers already apply advanced technology to improve the energy and hardware efficiency of their infrastructure, cloud migration is a good start for supporting green coding.

    Microsoft developed eight principles of sustainable software development for engineers to follow when they build, design, and deploy applications. You can apply these principles to all types of applications, whether deployed on-premise or in the cloud.

    Amazon released a sustainable architecture guide with strategies for applying sustainability practices to optimize AWS infrastructure compute, storage and network layers. AWS also provides guidance on applying environmental best practices for designing and operating workloads in the cloud.

    A Tools Roundup for Measuring and Reporting Carbon Emissions

    In addition to implementing sustainability practices in their business operations, cloud platforms offer clients tools to monitor and measure carbon emissions linked to cloud service usage and report their overall carbon footprint following greenhouse gas protocol standards.

    Google Cloud provides users with an emissions calculator. Using Carbon Footprint, you can track the emissions from running your applications. The tool lets you view and analyze data related to gross carbon emissions and use derived insights in emissions reports.

    AWS also offers the Customer Carbon Footprint Tool for emissions tracking. You can calculate their carbon emissions associated with using AWS services, track emissions after migrating to the cloud, and use the data for sustainability reporting purposes.

    Microsoft customers can access the Emissions Impact Dashboard to estimate their carbon footprint related to Microsoft Azure and Microsoft 365 cloud services. Microsoft also offers Cloud for Sustainability for tracking and managing carbon emissions. It gives you visibility into your organization’s environmental impact, aggregates data from various sources, and offers practical recommendations for reducing a carbon footprint.

    Energizing Thoughts

    Achieving “net zero” is not solely the responsibility of large-scale cloud providers. Businesses must also contribute. Itransition’s cloud consultants believe that if more companies move their IT operations from on-premises servers to the public cloud, overall energy consumption and related carbon footprint will decrease.

    By leveraging renewable energy sources, optimizing infrastructure for energy efficiency and employing innovative technologies, these leading cloud platforms can attract a cohort of environmentally conscious clients. Those users may consider switching to the cloud not only for direct business benefits but also to make their operations more sustainable.

    Photo credit: Aimable Mugabo on Unsplash

  • Reducing Energy Consumption With Cloud Cost Efficiency

    Reducing Energy Consumption With Cloud Cost Efficiency

    A new study from Stanford University found that it takes 75 gigajoules per year of energy for a person to have a good, long life, but the average American uses nearly four times that amount: 284 gigajoules/year. In fact, the U.S. consumes 17% of the world’s energy while accounting for only 4% of the population. 

    It’s not a new call to action that we need to do more to reduce our energy consumption. Corporations are starting to take action by implementing environmental, social and governance (ESG) programs. However, digital infrastructure is a huge contributor to energy utilization. The collective cloud now has a bigger carbon footprint than the airline industry. So, when enterprises are evaluating and managing cloud costs, they have to look beyond the economic costs and also consider the environmental cost and potential harm to the planet—they have a responsibility to use cloud services efficiently with zero waste.

    So, the questions to ask are: How do you know if your organization is using the cloud as efficiently as possible, and how do you prove the software you’re developing is cloud-efficient? An organization can have a major competitive advantage if they make cloud cost efficiency a priority for all teams involved—especially given the ongoing climate crisis and current market downturn. Below are three basic rules to ensure continuous cloud cost efficiency.

    1. Pay For and Use Only What is Needed 

    The cloud is a service that gets turned on and off, like a light switch. And, like a light switch, it should also be turned off when not in use. Also, as is the case with separate bins for trash and recyclables, organizations shouldn’t reserve large instances when a medium-sized instance will be acceptable. How much cloud is required will change over time, but it’s rooted in knowing who—which team, application, etc.—is using which cloud resource for what purpose at any given time. Ideally, no cloud resource should be left untagged and no cost unallocated, even for shared resources. Organizations can then focus on eliminating unused and underutilized resources.

    2. Understand the Impact

    Take advantage of tools that measure the carbon footprint of cloud usage. When organizations can reduce their footprint, it saves money and impacts other business metrics, such as cost of goods sold (COGS), employee satisfaction and even customer experience. Experiment with different technical levers and see how they impact the cloud costs—this will also lead to smarter choices. By empowering engineering teams with cloud cost data, organizations will enable greater efficiency from the beginning of the software development life cycle.

    3. Cultivate Conscientiously

    Cloud consumption will increase as a business grows—but is it growing efficiently? According to the Flexera 2022 State of the Cloud Report, optimizing usage is the top cloud initiative for the sixth year running, as cloud costs can spiral out of control quickly for a growing SaaS business. With accurate budgeting and forecasting capabilities, organizations can take advantage of long-term savings plans and reserved instances with confidence. In addition, addressing cost anomalies quickly will assist in the stabilization of growth. Not to mention the fact that cloud cost management products offer automated recommendations; the faster users act on cost-cutting alerts, the more money and energy will be saved in the long run.

    When an organization is reviewing cost reports and deciding which infrastructure changes to make, they should also give engineering teams real-time visibility and control over cloud costs so they can act faster and more ethically. With a corporate focus on cloud cost efficiency, organizations can brag about their reduced carbon footprint and be confident that their “Go Green” attitude is benefiting customers, employees and shareholders and, above all, the planet.

  • 5 Steps to More Sustainable DevOps

    5 Steps to More Sustainable DevOps

    The rise of remote workforces, cryptocurrencies and super-sized data centers brings to the forefront a concern in tech development that doesn’t get enough attention: The impact of computing and advanced technologies on the environment.

    About six months into the pandemic, people began to notice cleaner air, clearer water and an overall calming effect on the environment in the reduced presence of industry. Memes were created and widely circulated that suggested maybe we were the problem after all.

    That lasted for about six weeks before cabin fever set in, and we became impatient and ready to get back to business as usual.

    In the time between the last quarter of 2020 and the sudden waxing and waning of NFTs, a few timid voices again raised concerns about the impact of super-computing and other technologies on the environment. Those concerns eventually became muffled amidst socioeconomic and political turmoil, fears about inflation, staff shortages and logistical issues surrounding supply chain disruption.

    App development tried to fill some of those gaps and new data centers appeared as we struggled to find our footing again in a post-pandemic world.

    While environmental issues have been a matter of growing concern for decades, the past few years have put a particularly intense focus on the issue, with entire industries growing up around everything from climate-friendly investing to carbon offsets, and more. The environmental impact of technology has become an issue yet unresolved in spite of a growing focus on sustainability.

    Addressing the Elephant in Your Staging Area

    The typical DevOps journey focuses mainly on how app development will impact an organization. Rarely does it address how development impacts the environment.

    In addition to factors like improving time-to-market, reducing human error, debugging and making financial resource management more efficient, part of your DevOps strategy should include ways to reduce your carbon footprint and impact on the planet.

    First, it helps to understand exactly how technology affects the climate and depletes natural resources so you can incorporate sustainable development into your plan in a meaningful way.

    • Carbon emissions: It’s estimated that in 2022, there are already more than 16.5 billion mobile devices in use worldwide. Just one iPhone emits up to 86kg of CO2 over its life cycle, and 80% of that occurs before it even gets into the hands of consumers. This is just the tip of the carbon emissions iceberg, and it will only get worse.
    • Power consumption: All of that carbon comes from somewhere, and taking a look at energy consumption from just one slice of technology provides a glimpse into just how heavily computing contributes to the problem. As of 2020, data centers used about 416 terawatts of energy annually. The Bitcoin network alone consumes more power than all global data centers combined. A single NFT transaction consumes 82 kWh of power and emits 48 kg of CO2.

    Even relatively passive use of technology, like video streaming and remote collaboration, for example, has the potential to consume more power than entire countries. Add up all of the hours of Netflix, Zoom meetings and other remote activities and ponder the implications.

    • Waste: Despite the number of devices in use, very little hardware is recycled. Electronic waste comprises 70% of toxic waste worldwide, and it’s estimated to total 40 million tons annually.
    • Water consumption: You don’t often consider mixing water and electricity, but all of those data centers need to be cooled somehow. Internet usage alone uses 3,000 liters of water per person each year and emits 2,000 kg of CO2.

    Cleaning up Your DevOps Process for the Good of the Climate

    To become part of the solution, it’s important to do more than just invest in green businesses. Here are some steps you can take to clean up your DevOps process and become part of the solution rather than contributing to the problem.

    Identify Areas of Vulnerability

    Software engineering and DevOps are increasingly embracing new territory and emphasizing sustainable engineering. The first step in the right direction is to become aware of how power and resources are consumed during your development cycle.

    Consider:

    • How your power is generated. For example, are you dependent on fossil fuels or more eco-friendly methods?
    • How often are you replacing or recycling hardware and other physical components? This is a goal in waste reduction.
    • How are you cooling data centers and computing equipment? Are your efforts at maintaining optimal temperatures wasting resources?

    Balance the Three Areas of Sustainable DevOps

    In the realm of sustainable engineering, the process can be broken down into three categories: Technical, operational and environmental. The goal is to balance these aspects to monitor and optimize the development process and do the least amount of damage possible.

    Enforce Sustainable Development Practices

    Once you’ve identified areas of risk and set goals for sustainable software engineering, use the results to create and enforce a set of development best practices that better support environmentally responsible design and production. If you need some help or ideas, you can model your own initiatives after these emerging standardization principles.

    Become Part of the Green Tech Community

    In 2021, more than 200 countries signed the Glasgow Climate Pact, solidifying their commitment to reducing their carbon footprint and resultant environmental damage from tech development and use. The conference brought together stakeholders from businesses, government agencies and others to share information and create standards and best practices for sustainable computing and tech development.

    Incorporate Tools That Support Sustainable Development

    Tech giants like Google, Amazon, and Microsoft are creating tools to help DevOps and IT monitor and measure the environmental impact of everything from cloud computing to app development. Seek out and incorporate these tools into your own set of best practices or work on creating your own solutions.

    Final Thoughts

    Tech development is intended to improve our quality of life and reshape how we conduct business. There’s no reason that intention shouldn’t extend to the world in which we live and engage in commerce.

    The first step toward combating climate change without negatively impacting development is understanding how technology affects our environment. Then, we can make informed decisions that support responsible, sustainable DevOps.

  • Customer Demands Outpacing Business Requirements

    Customer Demands Outpacing Business Requirements

    As more organizations adopt agile and DevOps, many recognize quickly that the related gains are significant but further business efficiencies can be realized.

    IT and the business now are working closer than ever. No longer is the business throwing requirements over the wall into the IT “sausage factory”—they’re now an integral part of the entire process. IT has finally transitioned into a profit center.

    In the application economy, it’s not the layout or cleanliness of your brick and mortar store nor the friendliness of a customer service representative that makes your business successful. It’s the application’s user experience.

    As a result, the gains we’re seeing must be optimized continuously. One of the biggest challenges we face today lies in how we get business requirements translated into IT output, at the speed of business.

    In the old days, it was easy to move your best-selling, highest margin products into the ideal location or open another checkout when the lines got too long. With today’s virtual stores, the question becomes, How can we quickly pivot to tend to our real-time customer needs and shareholder expectations?

    We must be able to deliver software faster, and to do that, we need to marry our strategy to execution and delivery. We must optimize across the entire business to create true agility that paves the way for reactive and proactive acceleration.

    Case in point: If you optimize execution but not delivery, you’ll be creating software that cannot realize value at the pace of development. In reverse: If you optimize delivery but develop software slowly and poorly, your efficient delivery process will merely sit waiting—or worse yet, deliver poor quality software quickly.

    As a result, we must optimize all three of these areas while working in conjunction, overlapping and providing constant feedback and properly timing the impact of revenue and potential risk to customer experience.

    Unsurprisingly, to support all of this, we’re also seeing broader adoption of an end-to-end solution stack that supports acceleration of process from ideation through outcome. Let me walk you through this scenario:

    Your business is managing your strategy through the lens of its portfolio. As changes are set in motion at the highest levels, that data must be tracked—how much it costs to implement new functionality, how much time it should take and what ROI looks like—along with constant reviews to inform ongoing decision making.

    Your portfolio decisions are then loaded and tracked systematically at the project level, with resources assigned systematically to deliver the designed functionality through epics and user stories. Related data must also be made available in real time to be viewed at the program, project, epic or user story level, providing complete visibility from the level of developers all the way up to the board of directors.

    Simultaneously, your user stories must be imported into a system that turns them into test cases and test automation assets, then builds the test data synthetically to validate each test case. Once the data is generated, it’s imported into your service virtualization system, where application behavioral virtualization eliminates the need for constrained and non-existing back-end systems, simulating an end-to-end environment for any application that is being tested. This also should update your virtual services automatically with the data required for the test cases and any planned test automation.

    Let’s pause and review what we just did.

    We’re now managing our new functionality items across portfolio, program, project, user story and resource levels, all in real time. We’ve automatically created our test cases, test automation, test data and virtual services, all from the epics and user stories.

    So what have we done? We’ve provided the visibility and insight necessary to make business decisions in real time and track progress. We’ve also also minimized the need for test-case designers (or the business analysts that create them), test automation engineers, test data engineers and the DBA support for test data, freeing these experts to focus on other activities.

    Hopefully, we’ve achieved the desired result of massive reduction in resource allocation, acceleration of the entire software development life cycle, elimination of error-prone manual tasks and, most importantly, elimination of the ambiguity involved in translating actual requirements into test cases.

    Finally, we’ve now got all the necessary elements—team execution, prioritization by value, connection of value to execution, a platform that provides a single source of the truth, communication, and metrics—that will allow you to focus on creating value for your customers, instead of simply creating process.

    Transformation is difficult. Culture/environment eats process for breakfast. However, by focusing on changing your entire approach instead of merely recasting process and teams, you can truly change how you provide value to your customers and shareholders.

    This is how we translate business requirements into innovative software at speed.

    For added perspective on all things DevOps and Continuous Delivery, join my colleague Aruna Ravichandran for a live webcast highlighting the details of her new book “DevOps for Digital Leaders”—it’s sure to be an exciting discussion.

    — Ron DeCanio

  • Don’t Make Me Code: Environment Protection

    Don’t Make Me Code: Environment Protection

    Thanks for listening to “Don’t Make Me Code,” a Heavybit podcast that discusses developer experience design and the unique challenges of building developer-facing products. “Don’t Make Me Code” is hosted by Steve Boak, co-founder and CPO at Opsee, and David Dollar, co-founder and CEO at Convox.

    In this episode, Steve and David are joined by Sean Li, lead product designer at Docker. Sean, Steve and David discuss Docker’s acquisition of Kitematic, the friction of attempting to replace a developer’s existing tool, and the increasingly prominent role of design in developer tools.

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market.

    [soundcloud url=”https://api.soundcloud.com/tracks/274576622?secret_token=s-QHiyf” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

    Steve: We’re calling this episode of “Don’t Make Me Code” “Environment Protection,” and we’re here with Sean Li, lead product designer at Docker and one of the founders of Kitematic.

    Sean: Thank you.

    Steve: Thanks for being here with us. This is a really exciting conversation for me because we get to talk to a product designer for a company like Docker.

    Sean: It’s good to be here.

    Steve: Kitematic is a real interesting project for a bunch of reasons. I mean, it caught the interest of Docker. It’s also proven to be a really novel bit of development environment technology. And so we’re curious how it all got started.

    Sean: It got started in a university dorm room. I was a student from University of Waterloo in Canada, and the school actually offers a pitch competition. So we had this idea around making development environments easier, and so we pitched the idea and won. That’s how we got enough money to get started.

    Steve: Wow, and was it at all tied to Docker at that point?

    Sean: Docker was actually what we used for the back end. At the time, Docker was version 0.3. And then we’re on Hacker News, and we’re like, “Oh, this is interesting. It could be super useful technology to do what it wanted to do.” Our idea was essentially like Dropbox for your code.

    You get a Dropbox-like icon on your task menu, and then you can put code in it. For example, Django, it would just run it for you. And you can see it on the browser.

    Steve: Oh, nice. And so you have your production environment there, compiling for you and ready to go.

    Sean: Yeah. Then, when you added the code, it will sync to the cloud environment and then update right away.

    Steve: Nice. That’s awesome. It’s like a step beyond GitHub. It’s not just committing the code; all the CI and everything is built into this one workflow.

    Sean: That’s like the future plan right at the time, but at first, our MVP was super simple—just syncing code to a remote server and then seeing the changes.

    Steve: From the beginning it was implemented as a desktop application, you said like a Dropbox tray application.

    Sean: Yeah, because Dropbox was obviously the inspiration.

    Steve: And so why a desktop application?

    Sean: At the time, we actually didn’t realize the power of desktop application yet. At one point we used to pivot a lot, as startups usually do. And then we’re talking to customers, and they start realizing what we’re using underneath.

    We talk to Canadian Tire, the biggest retailer in Canada. They were looking for something like this, and they’re like, “Are you using Docker underneath? We want to use that.”

    At the time, the product we have is in the cloud, like an on-prem web browser setup. And then we started thinking of, instead of abstracting away Docker, why don’t we embrace it and then make it easier for the customers? Then we start brainstorming ideas, and it came across that having a desktop application is actually super beneficial.

    It’s like the best platform for developers, because they can import their code super easily. They can open a directory instead of having to upload files in a browser. You can also get a lot of access to their desktop, so once your tool gets more powerful, there’s more things that you can do.

    It’s also super cool because we use Chrome in an electron shell. And we wrote the UI in React, so that means we only have to worry about how the UI runs in that one browser, instead of having to worry about browser compatibilities across the board.

    Steve: So it’s not something React needed, it’s just running in a web view in the electron browser.

    Sean: And we make it feel as native as possible.

    Steve: All right, nice. So it’s a true desktop app in many ways, but specifically the UI, it’s a web UI.

    Sean: A lot of inspiration comes from the Atom Editor by GitHub. They’re using the same technology.

    Steve: And so this whole bit was open-sourced from the beginning?

    Sean: We were working on it, and then we open-sourced it.

    David: I’m curious what made you decide as you’re releasing this tool. Was open-source service a strategic decision, or you figured you could get more users by doing that? Or is it just wanting contributions from the community? Could you talk through a little bit of your inspiration behind that?

    Sean: I think the biggest part is if it’s something that touches their code, it’s really important that the developer trust it by seeing what the code is like.

    We’re really open about what we do, and also the part on gathering the feedback from the community is super, super helpful. I feel like, in general, open-source projects get more feedback from the community.

    Steve: With developer tools it seems like a great way to encourage participation. If you’ve got an open-source project, you’re inviting people to contribute. Obviously, our Opsee product for example, it’s closed, a SaaS application. So we don’t have the level of community support from developers that we would really like in some ways.

    Sean: We hired an engineer from Docker because he was a maintainer and he was super passionate about the project. It really helps on that front as well.

    Steve: Following from that, you launched this to an open-source community, did you have an idea of the kinds of users you were targeting at that point?

    Sean: We sort of did from the original product that we had, the Dropbox-for-code product. We had a signup list. A lot of these users are more leaning towards willing to use UIs and prefer something simpler. The super active ones are actually consultants that work on multiple projects.

    Steve: That’s an interesting segment. People there, maintaining a lot of projects, and they’re looking for an easy way to keep track of all that stuff. And Kitematic fit that mold.

    Sean: Yeah, and Docker being isolated also provides that value.

    Steve: That too. Now, if I’m maintaining multiple projects, I can have a Docker environment for each one. The app makes it very easy to move between those. And so specifically the React UI and the GUI, what was it like having that be part of the open-source project? Did you get contributions for that as well, or was that entirely internal?

    Sean: The React UI helped us in a way, because React is, according to a Google trend, almost on the same trajectory as Docker. So there are a lot of people willing to work on something that’s built in React. It was in a way accidental, because when we started, it was a really good technology to use.

    Steve: Did you have any designers contributing to the project?

    Sean: We do have design-minded people but not professional designers.

    Steve: For example, you’re a lead product designer at Docker and you, I assume, identify mostly as an engineer, or your background in coding. But there’s definitely this hybrid world in the developer tool space.

    Sean: Definitely. In the beginning we had hackthons. A lot of participants were trying to add features to Kitematic, then make a huge effort on figuring out the right UI right experience to build there. By default, I think what I wanted is sort of like designing an OS.

    A UI is very extensible, and you want to figure out the right points where you can extend on it. You actually focus on per component and really set an example of how you extend the current UI. When people contribute, it can follow that pattern. And you only had to make slight adjustments to it.

    Steve: That seems true of open-source projects, generally, too. You want build a broad base that people can build on top of and customize.

    Sean: Yeah, but the initial effort has to be really strong. Because otherwise you will get swayed by different opinions. And design by committee isn’t always a nice thing.

    David: That’s pretty interesting because you oftentimes see open-source projects that are sort of notorious, especially visually, for bad design or design by committee that ends up being a little too weird. I can think of some Linux desktop managers that I won’t name, but Kitematic is actually a beautiful application.

    Sean: Thank you.

    David: I’m curious how you managed to maintain that, even when you’re doing community-driven design.

    Sean: I think a big part of it is keeping focus and actually be willing to cut things. In the beginning, Kitematic actually had build, you can actually build an image and then push it. But to keep focus and make things simple before we figure out the next steps is actually making it run content only.

    Essentially the focus of Kitematic was helping users install Docker on their computer. You know, in a visual way, it feels very reliable. We solve a lot of underlying issues with VirtualBox in the beginning. And then after that choose a beautiful catalog where you can click one button and run a container. And then that’s the experience we were aiming for and focused on. So it’s super obvious what to do.

    Steve: Did you ever get push-back on those decisions from the community where you had to assert your position strongly there?

    Sean: No, I think the community is mainly supportive. What I had to manage was people trying to add too many things that are not focusing on that road map currently.

    Steve: I think I remember you saying, on the Software Engineering Daily podcast, that you did end up cutting quite a few things from the product after a bit of time. Can you talk more about that? You were trying to clean it up?

    Sean: The one thing that was cut was building images from it. Even though it’s a super important thing, we decided to delay it because we want to do it right. Instead of releasing something super early, and then get sidetracked into different things, we want to keep focus until we figure out this is it.

    And then release that as a whole. Talking about cutting more, the next version of Kitematic is sort of Docker for Mac. It really solved the core issues that Kitematic was trying to solve in the beginning, to install Docker reliably on people’s desktops in a way that it almost feels like it’s seamless.

    You don’t feel like it is running inside a VM at all, and that’s the goal in the beginning. You install Docker for Mac. When you open the terminal you can type “Docker run,” and it just works.

    Steve: Had the Docker for Mac project begun before the Kitematic acquisition?

    Sean: It was after the acquisition.

    Steve: So you were involved with that from the beginning.

    Sean: Yeah, I was the founding member of Docker for Mac.

    David: So it’s interesting to think about this this sort of internal debate. I guess with most design questions it’s customizability and configuration versus limited options, and this curated a beautiful experience. I feel like that happens even more with developer tools.

    It seems like Kitematic and Docker for Mac, some of these tools, are definitely trending towards the latter there, where you’re removing some of the optionality of Docker to make a better user experience. I think that’s really interesting.

    Sean: I think the two tools are, in a way, more complimentary. People usually use Kitematic by having the Kitematic UI side by side with the terminal. So they like the transparency that they’re getting from the Kitematic side, and the sense of it feeling reliable.

    “I see things are running. I can check the logs super easy.” On the other end, the terminal is how they’re used to working before, and that was sort of expected in the beginning. And then you go from there. You never want to displace a tool that they’re already using, one they’re so familiar with.

    So instead we embraced that but made Kitematic more of a complimentary to the Docker CLI.

    Steve: That’s really interesting. I’ve seen similar comparisons made with GitHub and some of their tooling. GitHub has their Mac app and their web UI and stuff like that. And I found myself going to them for things like diffs and comparison, merge states, something where I want to get a lot of text or get some status update.

    But for actions, if I want to do merges, everything I’m actually doing with it I’m still doing through the command line. But that’s a really interesting comparison, because it sounds like you’ve made the same distinction. To view things, maybe you go to the UI. But to actually take action?

    Sean: GitHub desktop is like a huge inspiration for all these decisions as well.

    Steve: I never really heard that distinction made this clearly, that there are certain things that developers are going to continue to want to do through the command line and through terminal. But that we can make the experience better in some ways, like just figuring out whether a container is running or not. That’s really nice to have a UI to see that all the time.

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market. Throughout the program, founders work on developer traction, product market fit and customer development. If you like what you hear, be sure to subscribe to Heavybit’s Podcast Network on iTunes.