devopsy.kinsta.cloud

Category: Blogs

  • Redefining Continuous Security for DevSecOps

    Redefining Continuous Security for DevSecOps

    In the mobile app development world, security often takes a backseat to developing features and delivering the app. In fact, the 2021 Verizon Mobile Security Index found that 45% of organizations sacrificed mobile security in order to “get the job done.”

    It really shouldn’t come as a surprise. Certainly, it seems counterintuitive that mobile app development organizations would spend so much time and money to create an exceptional Android or iOS app and then fail to protect it against rooting, jailbreaking, reversing, hacking and other kinds of malicious manipulation. But the average mobile developer releases 12 apps each year; a frenetic pace that requires development to take place in parallel, without ceasing. Schedules and budgets are tight, and competition is fierce. Coding security into an app is both expensive and time-consuming, increasing the risk of a delayed release or budget overages.

    In many organizations, if security is implemented into a mobile app at all, the process takes place during penetration testing. That’s too late, and it’s extremely inefficient. Waiting to implement security after development and delivery are essentially finished will anger developers because now, they have to dive back into their code to make complex changes to work they thought was finished. The code is no longer fresh, so it’s going to take more time than it would have if security implementation had taken place during the development process itself.

    But integrating security into the development process is no simple task either. Imagine two friends are spinning a couple of jump ropes. Jumping in the middle without stepping or tripping on either of the ropes while they are moving is difficult. Each time a security feature is introduced into a mobile app’s software development life cycle (SDLC), the person building the security could step on the rope. Building security features takes time, and they are hard to build and maintain.

    Our Oversimplified Model of DevSecOps

    To solve this problem, DevSecOps was introduced to resolve this conflict and overcome the challenge of integrating security into the mobile SDLC. The idea is that organizations can develop features and incorporate security simultaneously. So far, much of the emphasis in DevSecOps has been focused on the processes development, security and operations that teams use to build, protect and release apps. People have done heroic work creating cultures of security and secure coding practices, which has moved the industry forward toward more secure mobile apps for everyone.

    Let’s take the jump rope analogy a bit further. One friend holding the ropes is the development and engineering team, while the other is the ops/release team. The ropes each represent an iOS and an Android app. In most organizations, the ropes are moving at blazing speeds, as apps are churned out one after the other. Meanwhile, on the sidelines, there’s the security team, whose job is to make sure the ropes meet security objectives, jumping in where needed, all without stopping the ropes from spinning.

    The trouble is that each group has different skills and objectives. Developers aren’t typically security engineers, and security teams don’t typically have developers. Neither group has the resources or skills to meet the needs of the other, and whenever they try, one of them trips on the rope.

    Mobile DevSecOps, Meet Continuous Security

    The only way to keep the current breakneck pace of app releases going while simultaneously providing security is to introduce as much automation as possible. AI systems can fuse security to an app more cost-effectively and consistently, complete with validation that the features required have been implemented. It’s different from code scanning, which occurs after the app is built and leaves remediation to the dev team. I’m proposing that the implementation of security itself be automated.

    The growing threats to mobile apps are too significant for development teams to ignore, but so are the market pressures that force such short delivery timescales. The only way out of this dilemma is extensive automation. Otherwise, the dev and sec teams will keep continuously tripping on each other’s ropes.

  • The State of DevOps Is Just Fine

    The State of DevOps Is Just Fine

    There is a growing amount of hand-wringing about the state of DevOps; that adoption is not progressing apace, or that the full benefits of the methodology are not being realized by the majority of adherents. That we can and must do more and do it better, etc.

    That is just stupid. Or, my first reaction: “Bunk!”

    Yeah, I called an idea stupid. No, I didn’t call you stupid. Don’t give me a reason to. The world is full of stupid ideas, and this is one of them. Here’s why.

    DevOps has seen a decade of unprecedented adoption – yes, unprecedented. PCs were not adopted by businesses at the rate that DevOps was adopted, once it caught on. Virtualization took the business world by storm and, frankly, wasn’t even close to the adoption rate of DevOps. Agile greased the wheels and got people thinking about better ways; we all knew the weaknesses of how we were doing things, and DevOps gave us an option that addressed those weaknesses. We took it. We ran with it.

    So talking about how it is stalled, when adoption is darned near-ubiquitous? Silly.

    Those concerned are further zeroed in on one aspect of DevOps – not enough culture change. Let’s face it—automation is easier, the ROI is more obvious and even when ROI is vague, the elimination of busywork from the schedule of developers and operations alike is huge. Some organizations were never going to move beyond that point; others eventually will, but aren’t in a rush. Organizational changes do not define DevOps any more than automation does—DevOps is the process of streamlining software creation and delivery—and both automation and culture change contribute.

    The “full benefits” of DevOps are … what, exactly? That is another silly part of the proposition that a slowing of DevOps adoption is negative. Automation improves the creation and delivery of software, silo elimination improves the creation and delivery of software… The full benefits of DevOps are improvement. That has always been the stated goal—to make it better, smoother, more repeatable. Wherever an organization is on implementation, it is almost guaranteed that their creation and delivery is “better, smoother, more repeatable.” So, benefits are accruing.

    And each organization has different needs. DevOps is a methodology. It has never been the perfect solution to every IT problem—though there are still pundits that will try to tell you it is. Automation is always a positive; Agile and DevOps—well, that is less true. You know your organization and your apps, so the “right methodology for the job” is absolutely your call, not some vendor’s or pundit’s. So, “adoption slowing” partially represents orgs/projects/apps that have opted not to pursue some of the more radical changes DevOps implies (yes, radical. Automation is just a logical extension of scripting; redesigning team organization and reporting relationships is absolutely radical by comparison).

    Which is a good place to leave off. Your apps, your org, your environment. You know what is going to do the most good. So keep doing it. Push for it if the org isn’t there yet, be the change that is needed. But be aware of cost/benefit. Sometimes, the changes being asked for just aren’t worth it. So make sure they are before you push too hard, and if they’re not, make sure you’re comfortable with why and can defend that decision.

    And keep rocking it. Those apps are delivering to users, no matter where you are in DevOps adoption. And that says it all about you and the team. Thanks, for all of your users that never think to say it.

  • Shoreline Platform Automates Repetitive IT Tasks

    Shoreline Platform Automates Repetitive IT Tasks

    Shoreline emerged from stealth today to make available a namesake incident automation platform that eliminates the need to manually perform the same repetitive tasks.

    Anurag Gupta, Shoreline CEO, said the platform is based on domain-specific language, dubbed Op, that provides a simple pipe delimited syntax to integrate real-time resources and metrics in a way that allows DevOps teams to invoke an orchestration engine to automate the execution of a task from the Linux command prompt. Op employs a syntax that is familiar to any IT professionals that currently use shell commands and scripting tools to resolve IT issues, said Gupta.

    That same Shoreline tool, however, can also be employed to create remediation loops that check for issues, collect diagnostics and apply repairs automatically in the background, he added.

    Shoreline

    Shoreline achieves that goal by first collecting metrics on a per-second basis via data collected from open source Prometheus monitoring software. Armed with that data, it then becomes possible to distribute queries to both collect data in real-time and run local loops in parallel to automate repairs, Gupta said.

    The platform employs the JAX and XLA frameworks for machine learning algorithms to reduce the amount of CPU resources required to compute metrics and create alarms. Wavelets are also employed to compress the input metric stream. Finally, queries are portioned across historical data stored in the S3 cloud storage service from Amazon Web Services (AWS) and real-time data collected from each node.

    All Shoreline components are designed to be fault-tolerant, added Gupta. Automation can still run locally to Shoreline backends, even when connectivity is lost. All processes have supervisors to restart when failing and reestablish connectivity.

    Finally, Shoreline provides controls to limit the scope of a manual operator action and automate executions in a given time period to help prevent any errors from cascading through an entire IT environment. That approach makes it possible to safely automate tasks in a way that makes it less likely outages will occur because, for example, a misconfiguration winds up being propagated across every system, noted Gupta.

    While IT environments are arguably more complex than ever, Gupta said it’s the repetitive tasks that take up so much of developers’ time. In the absence of any way to automate those tasks, an IT team will, over time, become increasingly burned out, which Gupta noted inevitably leads to mistakes being made.

    At the same time, Gupta noted the Shoreline platform makes it simpler to onboard new members of an IT team because much of the tribal knowledge that once had to be learned on the job has been captured within an automation platform.

    The arguments for automating IT have, of course, been growing louder and more frequent for nearly two decades. Most platforms that promise to automate IT have required a fair amount of expertise to implement and maintain. The Shoreline approach, in contrast, starts with a Linux prompt that many IT teams already routinely use to execute a range of tasks. The difference now is simply the level of scale at which those tasks can be performed with a minimum of programming skills.

  • Shopify Gives Devs More Creative Freedom

    Shopify Gives Devs More Creative Freedom

    Shopify’s Unite 2021 conference was held on June 29, 2021, and the e-commerce platform had some big, developer-centric news to share. Alan Shimel spoke with Shopify’s Glen Coates about the developer-first business model that is giving developers the most opportunity to build their businesses with a new 0% revenue share model, and how developers can leverage as much creative freedom as they want, from low-code capabilities in Online Store 2.0 to “max-code” custom storefronts. The video is below, followed by a transcript of the conversation.

    Alan Shimel: Hi, everyone. Welcome to another TechStrong TV segment. My guest this segment is Glen Coates. Glen is with Shopify. Glen, welcome to TechStrong TV.

    Glen Coates: Thanks, Alan. It’s great to be here, man.

    Shimel: It’s great to have you on. Glen, no pressure, but I think you’re the first person from Shopify who has been on TechStrong TV.

    Coates: There you go. _____ [inaudible due to audio distortion] it’s going to be all up from here, like you’re starting at the right place.

    Shimel: We’re starting at a low bar.

    [Crosstalk]

    ‒ it only gets better. We’ll see. Anyway, Glen, I think our audience doesn’t need an introduction to Shopify. We’ve all bought things online through Shopify storefronts and so forth, but why don’t we talk a little bit about you, your background, your position with Shopify?

    Coates: Right. I’ve been at Shopify a couple of years now. Before Shopify, I founded a startup called Handshake, and Handshake was a wholesale-focused e-commerce platform, so very much like Shopify but not focused on direct-to-consumer selling, just on wholesale. Handshake was acquired by Shopify about two years ago, so I’ve been at Shopify since the acquisition. In my time in the last couple of years at Shopify, I initially started out focused on wholesale, obviously, given my background. I spent most of last year focused on Shopify’s checkout, which is, obviously, a pretty important part of Shopify, and then about six months ago, _____ _____ product for what is called Shopify Core.

    If you’re a merchant, Shopify Core is like what’s in the box when you buy Shopify. It’s the online store, it’s the checkout, and it’s the back office admin that lets you set up and run your business. If you’re a developer, Shopify Core is the core developer platform, so the APIs, the dev tools, the docs, all the things that let you build apps and themes and work on the Shopify platform. Yeah, and, obviously, it’s a big responsibility and a really exciting role to be able to help the world of entrepreneurs start and try their business ideas.

    Shimel: Absolutely. Glen, just to give a little color, how many different Shopify merchant stores are there, whether it’s sheer number, percentage of commerce, or what have you?

    Coates: Yeah. Today, Shopify powers almost two million merchants. I mean, obviously, the last year has been kind of an accelerant to businesses going online, and that’s both been new businesses, people trying businesses for the first time, and it has also been traditional businesses going digital more quickly than they might have otherwise. But yeah, today, Shopify powers almost two million merchants worldwide, and it wasn’t that long ago that that was only a million. Even at massive scale, even being the world’s largest commerce platform in terms of number of merchants, it’s still growing very quickly, which I think just goes to the pace at which the world of business is going online, and how many people want some help with that.

    Shimel: Got it. Excellent. Thanks for all that info. If you don’t mind, let’s turn to the topic of today’s conversation, and I’m going to let you explain it, if it’s okay.

    Coates: Sure. Next week, it is Shopify Unite, which is our annual conference. Over the years, Shopify Unite has been focused on a combination of merchant and developer topics, but this year we’re really doubling down on developers, and really making it a developer-centric conference. The reason for that is sort of going back to the question you asked me a second ago, is Shopify was founded in Canada, and, if you go back five, six, seven years, Shopify’s mission has always been to make commerce better for everyone. But, if you go back half a decade, it was mainly North American merchants mainly selling apparel, mainly direct-to-consumer, which that’s a big market but it’s not the world of commerce.

    Over the last few years, Shopify has expanded considerably into new industries, new countries, new ways of welling, so wholesale as well as retail, and so we’re now in a much more diverse world of commerce, different businesses doing different things. As we sort of march down the road and try to fulfill that mission of making commerce better for everyone, that everyone is becoming a lot more diverse as we expand. Shopify can’t build all the solutions for everyone, all those different niches. While we have a great core product that includes many of the out-of-the-box things that people need to start and run a digital business, it’s not everything. We need the help of the world of developers to help build those solutions for the markets for the spaces that they are experts in to complement what is in Shopify Core, and really deliver everything that merchants need to successfully start, run, and scale a business.

    This year, we’re really focused on developers and helping them get onboard with our platform. There are really three main legs to that, I would say. The first one is mainly technical. I think for your audience, some of those details are important, like Shopify really is expanding to be PlanetScale commerce infrastructure, really becoming the power lines, the plumbing, the electricity grid that runs the world of commerce. So, we’ve done some things to really scale up our infrastructure that if you’re a developer building on Shopify, you can be confident your stuff is going to run at global scale without you really having to do anything. Our checkout can handle seven times the load that it could before. We’re now at greater than 30,000 checkouts per minute on a single shop.

    It’s interesting what’s happening to the world of commerce, like the world of social selling has made, and the way algorithms reinforce themselves in terms of distribution to drive traffic towards things that are trending. It’s become more important than ever that a merchant who blows up, whether it’s because of them being re-shared by an influencer or whatever it is, that they can capture that demand in the moment. Traffic is basically getting more spiky on the Internet. When things trend, they trend fast, and so Shopify already was the highest throughput checkout on the Internet but it’s now 7x higher, so merchants should never worry about not being able to make the most of those moments when they’re trending becoming more and more important.

    Shimel: It’s hyperscale, is what it is, Glen. We’re seeing it not only in merchants and commerce, but across everything. The Internet is big business, it is worldwide business, and especially with COVID, right? If you haven’t built your infrastructure to hyperscale, you’ve got trouble.

    Coates: Right.

    Shimel: That’s what digital transformation is about. That’s what the world is demanding right now, hyperscale.

    Coates: I imagine the readers, viewers of your site are not strangers to the world of what it takes to scale websites, and I think a lot of what Shopify tries to do is say, “Well, listen. We’ve figured that out for you. You’re a merchant with an idea. You’re going to come up with a new shoe or a new candle,” or whatever it is. Entrepreneurship is a risky endeavor, not everyone succeeds, but, when you succeed, like we really want you to be able to just capture the whole thing. The checkout works at one checkout a minute when you’re just starting out, and then, on your biggest days, it goes to 30,000 and you just don’t have to do anything. It just works, which is great. Kind of piece number one of Unite this year is Shopify really is PlanetScale infrastructure for commerce, and we already were the leaders and we’ve kind of gone up another multiple from there. Point two is really like, “As a developer, what things can I build on your platform? What are the opportunities for me to innovate, like where can I do that, and why is that exciting?”

    We’ve made some major updates to our online store, to our themes platform, which is obviously every merchant basically runs an online store with a theme on it. There is a new themes platform that allows developers to properly separate basically data and presentation into different layers in a way that makes themes more modular and extensible and kind of upgradable in the future. We have this powerful new data infrastructure that allows merchants and developers to essentially build custom data models inside a shop, and not just be confined to the out-of-the-box data model that ships with Shopify. There is now a much more powerful customization framework for both theme developers and app developers to integrate custom content into themes without having to hack the theme by hand and try to take it off the upgrade path, which is really great for merchants. We have also recognized that the Shopify online store is based on a web templating language called Liquid, which is similar to the templating languages that all developers are basically familiar with.

    We are also announcing, if you want to, you choose your own stack. If you want to build your website using React or something else that’s not our out-of-the-box stack, we’re also making available a new platform codenamed Hydrogen that will allow developers to basically choose their own stack, build online stores using whatever technologies they want, but ‒ and this is the crucial part ‒ still leverage a global infrastructure and hosting in scale and, “I don’t have to think about it. It’s just going to work,” on the Shopify platform, which is really great and really unique. Last but not least, I mentioned earlier that I spent last year on checkout. We are opening up for the first time the ability for developers to build checkout apps. Checkout is the piece of Shopify that it really matters. It’s where the money changes hands. It has to scale, it has to be super reliable ‒

    Shimel: Super secure.

    Coates: Super secure, super trusted, right, and trusted not just in the technical security sense of the word, but even just in the emotional sense of the word, like when I’m a buyer and I’m buying from an online store, when I see this checkout, does it feel familiar? Does it feel like something I can rely on? Am I comfortable handing over my money? Checkout is really where, in the _____ journey, the emotions shift from at the top of the funnel it’s kind of, “Okay, your brand, it’s really different. It’s exciting. I want to see differentiation. I want to be challenged and see new things.” But, when you’re handing over your money, the emotional tone is different, right? You’re not looking for excitement, you’re looking for predictability, right?

    Shimel: Yeah.

    Coates: Historically, Shopify’s checkout has been less customizable than the actual storefront pages higher in the funnel, and so now we’re opening up a new extensions framework for checkout that allows developers to build in apps that securely extend the function of Shopify’s checkout without compromising on the trust, the scalability, the speed, and all those kind of baseline, crucial things.

    Shimel: Very cool.

    Coates: That’s really cool. The last thing I’ll mention is we’ve talked about, “Okay, as a developer, if I build on your platform, is it just going to scale to the world?” The answer is yes. “Okay, so then what am I going to build?” Okay, so there are a bunch of new programming surface areas that we’re opening up for people to build apps and themes into, and then the last piece is, “What’s in it for me? Where are the dollars? If I start building your platform, am I actually going to make any money as a developer?” One of the things we’ve announced is _____ economic opportunities for developers. One is we’re cutting the rev share on apps in the Shopify app store to zero for the first million dollars in revenue per year, and, after the first million dollars, we’ve actually cut our rev share from 20 percent, which was already one of the lower rev shares in the industry, down to 15 percent. We’re really trying to help developers who have an idea for an app or an idea for a theme get that off the ground, no rev share on that first million bucks, and we really just want to help developer entrepreneurs get going as easy as we try to help merchant entrepreneurs get going ‒

    [Crosstalk]

    Then, the second one is that the Shopify theme store has historically not been open for submissions from any developer who wants to build a theme. There has been a sort of a curated set of themes there until now, but we’re actually opening up the theme store, so developers who want to build a theme and sell it to merchants will now have that opportunity that they didn’t before, which is also a huge market that is new.

    Shimel: Look, I think emphasizing the developer and the developer interaction in Shopify is huge. Glen, this is all great. I didn’t want to stop you when you were talking, but of course we’ve pre-recorded this show and it’s now playing after Unite has already taken place, I believe, on the 29th.

    Coates: Right.

    Shimel: But, for people who maybe want to see a replay of it or maybe get the highlights, is there a place we could send them to check it out?

    Coates: Yeah, if they just go unite.shopify.com, they’ll be able to watch the keynote and then dive into the other sessions that were part of the event and dig into whatever they would like.

    Shimel: Fantastic. Glen, thanks for a great recap on what happened at Unite and what’s going on at Shopify. Please come back on and keep us posted. You were wrong. You set a high bar. It’s going to be tough for people to beat, so come in and please keep us up to date on what’s going on at Shopify, especially with this renewed focus on developers and development options on the platform.

    Coates: I appreciate your time, man. Thanks for having me.

    Shimel: All right. Glen Coates on Shopify, about Unite, the Shopify conference here on TechStrong TV. We’re going to take a break and we’ll be right back with another guest.

  • From One-Click Deployment to One-Click Feedback

    From One-Click Deployment to One-Click Feedback

    What makes a group of individual contributors a team?

    You can look at today’s product development teams as an ensemble of craftspeople from different disciplines. Code builders, design artists, storytellers, and an orchestrator. Similar to an orchestra, their output is based on the ability of each and every one of them to work together in harmony, continuously and collaboratively.

    Let’s dig a bit deeper into today’s development methodology to see what this means in a practical sense.

    At a high level, we see three major steps: planning, development and release.

    1. Planning = Empower design craft
    2. Development = Empower code building craft
    3. Release = Optimize time-to-market (since there is no more time for nonsense!)

    Despite the fact that teams are supposed to work together and be very in tune with each other, when we look at the reality, it’s very different. We actually work in silos, nurturing black-box thinking. Instead of collaboration, often there are three separate units that comprise a whole, solely with interfacing endpoints.

    In such a configuration, it’s unavoidable that one unit’s priorities will be disruptive to another’s work, or flow. Without better integration of the actual collaborative parts of the work, in the form of frictionless and ongoing feedback throughout and during the end-to-end planning, development and release processes, eventually, your own unit’s priorities will take precedence over another’s.

    Engineering IRL

    A typical engineering process, whether it’s a new feature being developed, a bug fix or any other kind of collaborative work, usually looks like this:

    • A developer receives a design handoff and, from that moment on, is expected to deliver a working manifestation of the design specifications.
    • The developer gets to work (whether solo or on the dev team; independent of product or design, at this point) based on the specifications and starts writing the code.
    • Once completed, the code is deployed to a pre-release staging environment, where the designer actually experiences the result of their craft for the very first time.

    If you’ve been through similar processes, you’ll agree that, by this point, there is rarely time or tolerance in the process to iterate or provide feedback, nor correct much at all. More often than not, the mindset in fast-moving organizations is to stick with what we have ready to ship and just move forward. The actual “collaborative” part of the work is essentially bypassed. It’s really just a relay race of passing the baton downstream.

    But this engineering paradigm has its consequences. Ever tried to dissuade an artist from providing their feedback? Expect a pretty bad vibe in the room (or virtual room in today’s hybrid and remote team structure).

    This example, of course, is actually a virtual utopia of the development process. In reality, most organizations today have a far more destructive culture of continuous disruptions.

    Now, let’s spice up the scenario with some real-world interruptions that often break the ongoing individual flow.

    When a craftsperson is in the zone and creating, don’t interrupt! But what can you do when there are so many things happening in parallel? In small organizations that are just ramping up, most people are juggling much more work simultaneously.

    What often happens looks a lot like this:

    Jolene from sales requires a specific version for customizing a demo for a super important customer; Marko from support has opened 31 tickets you have yet to handle since it is a production issue that affects end users; your beloved single staging environment broke and you can’t review any new feature—oh, and don’t forget to attend the three meetings scheduled for today.

    Frustration, anyone? I like to call it the ‘multi-context bad habit.’

    Okay, I can already sense some eyebrows being raised, and I can almost hear you saying, “Yeah?! So what? We’ve always worked this way—what’s the issue??” Allow me to show you some numbers that may surprise you.

    “Finding flow is key, and interruptions are a drag. Minimal or no interruptions give developers an 82% chance of having a good day, but interruptions throughout the day decrease the chance of a good day to just 7%.”

    Eirini Kalliamvakou

    “Meetings are both awesome and terrible. Collaboration improves our work, but too many meetings can be a blocker; going from two to three meetings per day lowered the chances of making progress toward their goals by 60%.”

    Dr. Nicole Forsgren

    To summarize, these data points basically indicate that disruptions, interruptions and the “multi-context bad habit” ultimately have a tangible, detrimental impact on results and outcomes. They diminish successful outcomes and delivery times by orders of magnitude.

    Zero-Click Deployments as a Culture

    Fortunately, there are multiple practices and tools today that can be leveraged to dissipate the friction, break down the silos and improve the flow.

    This can be achieved by evolving from one-click deployment to zero-click deployments. Allow me to explain.

    Today, we have enough working examples that could (and should) be replicated more widely in engineering practices. Here are some examples.

    Preview Environments

    Preview environments (sometimes referred to as ephemeral or PR environments) provide, well, the opportunity to preview products. By allowing multiple stakeholders to review and experience the product throughout the development process, you shift-left the way you manage your development processes and are able to provide the relevant feedback and fixes earlier in the process. This basically means that for any PR you get a live environment that is shareable and independent from your staging environment. (I like to call this an in-development feedback loop).

    The JAMStack

    Another good example can be taken from JAMstack. When JAMstacking, consider using Netlify, Vercel or AWS Amplify to gain this capability for your team.

    Infrastructure-as-Code (IaC)

    If your project is non-JAMstack, you can consider building a similar preview environment through IaC solutions like Terraform or Pulumi. The downside here is that this comes with quite a bit of hassle, as you have to build automation for every single PR to have a dedicated shareable URL of the environment for review.

    This is great, though, because it democratizes the PR approval cycle by being more inclusive. Project managers, designers—practically anyone can review and approve the PR in development without having to wait until the end of the process to provide input. It’s easy to manage as it is isolated and independent of staging, which also provides always-on issue reproduction ability in the event that some kind of bug was discovered or tests need to be run during the development phase.

    But it also isn’t all roses and sunshine.

    There are some gaps and challenges that still need to be overcome for this to work. Some examples:

    How do we streamline feedback?

    Developers are used to getting comments from peers during code review in a language they can understand easily (for the most part) and quickly merge the input into their project. They don’t lose context by navigating away from the tool they’re working in (e.g. to Slack or Acme Corp. Task Manager), as it keeps them in their source code management environment (SCM). We need to think about how can we offer the same developer experience for everyone in the process to minimize PR turnover.

    How do we provide actionable and quality feedback?

    For example, UI and behavioral issue reporting are time-consuming, since you have to document and explain what, exactly, needs to be changed in order for it to be effective. Any wanted change likely involves the developer, which adds yet another disruption and interruption to their day.

    Taking Zero-Click Deployments to Single-Click Feedback

    If we want to optimize the developers’ flow, the next phase after simplifying the deployment aspects is to see how we add in the feedback layer in a way that isn’t intrusive.

    We need to now take this mindset and empower what I like to call one-click feedback.

    This isn’t a new concept, of course. Let’s take some inspiration from collaboration tools we all love like Figma, Miro and Notion.

    What’s magical about each and every one of these tools is the ability to provide contextual feedback. This is important as it enables contextual collaboration. Any user is basically one click away from sharing their feedback while remaining in-context, increasing the potential for feedback to be dealt with frictionlessly.

    This makes possible the following core values:

    1. Any person can easily point out something which requires the creator’s attention.
    2. The creator can instantly understand the feedback within the context of the project and what they are working on, and reply or tag another relevant peer for their point of view.
    3. The creator doesn’t leave their main work environment to prioritize the new task or give it the attention it requires. Just as designers do not leave Figma to apply feedback, PMs don’t need to leave Miro to apply theirs, and so on.

    These tools welcome feedback in an inclusive manner while enforcing a frictionless workflow. No one is messing with the creator’s flow as it is also happening asynchronously—no need for meetings, syncs or coordination of multiple stakeholders. This is also much more inclusive and relevant for today’s remote work culture, which requires investment in team communication through asynchronous channels and processes to be effective. (Here’s a great talk to watch on this topic; yes, the irony of interrupting your flow to watch this video is not lost. No, Really, Don’t Chuck Everything in Slack: Communications for Distributed Teams – from Florian Haas)

    Assuming you find some truth in this, I’d like to address the now apparent elephant in the room: Why don’t we introduce the same abilities for in-development collaboration?

    One-Click Feedback-as-Code

    We’re starting to see a trend where framework-coupled companies like Netlify and Vercel, for example, are adding collaboration aspects to their offering. Netlify, in fact, is acquiring a company, FeaturePeek, to embed collaboration features on top of their preview environments, and Next.js starting an early access rollout of their Next.js Live product.

    Imagine developers getting inclusive feedback during the PR approval cycle; not only comments about their code from peers but also UI, design and behavior comments with all of the needed assets and context to move forward without leaving their work environment! Such a shift will have a measurable impact on time-to-market, quality and velocity when employing such a workflow.

    The main premise here is that to achieve better metrics associated with flow (as noted above by Dr. Nicole Forsgren), we should not mess with the flow. The benefits of reducing the friction and interruptions in creators’ flow are exponential and will enable us to get closer to working in tune and in harmony (if we stick with the orchestral references) or simply more collaboratively, as a team where each individual is always maximizing the time they are able to be in creation mode, without silos or black boxes.

    What do you think? What’s your view of how teams should work together? How do you handle flow within your organization?

  • DevOps Database Platforms Slash DX Bottlenecks

    DevOps Database Platforms Slash DX Bottlenecks

    An enterprise with many databases and various data requirements for DevOps continuous delivery presents a problem. For example, test data provisioning is a challenge today, particularly in pre-release testing of database updates. Standard practices involve shared database environments that need to be maintained from one test to the next, slowing test cycles and generally not fitting into an automated CI pipeline. As I explained in A New DevOps Database Platform is Needed, at best, it makes things chaotic; at worst, problems with database integrations with DevOps is a gross impediment to overall organization agility—which undermines the very purpose that DevOps is meant to serve.

    A recent whitepaper, A New Kind of DevOps Database Platform, indicates that there are multiple reasons why a new kind of DevOps database platform is needed, which are:

    • Compatibility requirements
    • Integration with current CI/CD pipelines
    • Integration with portfolios of value stream management
    • Infrastructure cost efficiency
    • Productivity for developers, testers and operations
    • Security and governance
    • DevOps performance

    The paper explained that a DevOps database platform requires the following capabilities to satisfy these requirements.

    • Automated database provisioning: the ability to deploy a database using automated procedures.
    • Database cloning: writable database environments are delivered on demand, based on a built versioned image.
    • Distributed repository: database images can reside on Linux and Windows servers, as well as storage systems.
    • Simple declarative builds: a simple, predefined method to make the creation of versioned data images simple, while enabling user/group access controls, data masking and other data engineering functions.
    • Scalable data cloning: database clones are served on demand, with many simultaneous clones served from a single image.
    • Comprehensive database support: the repo supports all common relational, NoSQL, machine learning and file-based data stores.
    • Versioned databases: each image becomes a versioned, immutable DevOps artifact.
    • Deploys equally to all cloud environments: DevOps databases can be deployed and operated on any on-premises infrastructure or cloud.
    • Cross-platform:  DevOps databases can be deployed and operated on common operating system environments such as Windows and Linux.
    • Security features including access management, data masking and encryption: database images easily incorporate access control, data masking and synthetic test data via SQL scripts, batch files or command line tools.
    • Compatible with CI/CD platforms:  DevOps databases can be deployed and operated equally well in multiple CI/CD platform tools such as Azure DevOps, Jenkins and CloudBees.
    • Compatible with containers and container orchestrators: DevOps databases can be deployed and operated equally well in multiple container environments such as Docker, Kubernetes and Red Hat OpenShift.
    • Deliver writeable data at the speed of DevOps: Deliver writable databases in seconds.
    • API for easy integration with DevOps tools: An API is available to enable integration of the DevOps database control plane with other tools.
    • Audit logging: The DevOps database includes a complete audit log of operations.

    Transforming to the New Database DevOps Platform

    A DevOps database platform in an enterprise requires more than simply buying and installing software and telling everyone to use it. With multiple entrenched database platforms already in place, there are practical and political considerations that must be overcome. Introducing any change to a large group of applications in an enterprise can be chaotic, and will often be more costly and take too much time if the changes are not compelling.

    To be sufficiently compelling, the database DevOps platform needs to be affordable, easy to understand, easy to set up and use with a wide variety of CI/CD pipelines. The following will be sufficiently compelling benefits to drive adoption:

    • Versioned, secure database environments or images managed as a DevOps artifact.
    • Images can be built and managed by the DevOps team, without requiring new infrastructure.
    • Multi-DB and multi-TB data environments in seconds.
    • Database environments can be served on demand for a CI/CD pipeline.
    • Lower-level database environment infrastructure is streamlined, with a single VM capable of supporting many simultaneous database environments which drives an immediate cost savings and positive ROI.
    • Data security and governance benefits with versioned database environments, with built-in and auditable security policies.

    What This Means

    Digital transformation is imperative for modern enterprises and organizations to remain competitive. However, the transformations of many enterprises and organizations are seriously impeded by the challenges of integrating databases into their DevOps application pipelines and value streams. A new DevOps database platform can allow the databases to be treated like any other DevOps artifacts that are orchestrated and automated within the DevOps toolchains.

    Suggested resources for automating database environment delivery include Windocks, Cohesity and other storage appliances that provide virtualized (cloned) database environments that can be adapted for DevOps purposes. I want to particularly acknowledge input from Windocks, who has introduced a DevOps data repo that features database virtualization on standard Linux and Windows servers, for versioned data environments and CI pipelines and cloud-native support for data delivery for containers, Kubernetes and conventional instances.

  • Are You Wasting Money in the Cloud?

    Are You Wasting Money in the Cloud?

    I’m not the first person to point out the issues with Andreessen Horowitz’s blog post outlining why Dropbox is repatriating from the public cloud to data centers and saving an enormous amount of money. But while others have brought up valid points about how Dropbox is not representative of most companies and that the value in public cloud is in speed, not cost savings, I wanted to address a different angle: How do you, as an IT leader, know if or when you should move your cloud workloads back to the data center? How do you evaluate the ROI on the cloud in general?

    I want to talk through some of the factors that companies should be aware of when they’re thinking about whether or not it would be appropriate to repatriate a workload—and perhaps give some IT leaders peace of mind that staying in the cloud is OK.

    How Mature is your App?

    The earlier you are in the application’s life cycle, the more critical access to cloud infrastructure is. Early in the application’s life cycle, you need to get things out the door and test them with real people. You don’t, at this point, actually know how users will interact with your application or how the application will perform under the stresses of actual use. You also don’t know how much it will cost to run.

    At the beginning, quick iteration is also very important. There will undoubtedly be things in the initial release that go wrong—you need a way to quickly adjust course and improve.

    As the application matures, everything slows down. Your information about the application accumulates, but quick iteration becomes increasingly less important. It’s not until the workload is fairly mature that you can begin to understand how much it costs to run in the cloud and can compare that with how much it would cost to run on-premises.

    At the early life cycle stages, using a public cloud provider is extremely valuable because it allows you to get the application into users’ hands quickly and to iterate fast. As the application matures and changes are made less frequently, moving it back to a data center could make sense—at least in some cases.

    Internal Skill Sets

    Running an application in the cloud involves a different skill set than managing a data center. If you don’t have the internal skills needed to staff your data center, that can add not just cost, but will also increase the risk that something goes wrong.

    If you’re considering moving from cloud to a data center, taking a critical look at your internal skill sets is essential. Without a skilled team to manage the data center, you’re better off staying in the cloud even if it’s expensive. And yes, you can hire the skill sets you need, but that requires both time and money.

    Criticality

    If you have a workload that you never want to go down—because it is mission-critical, because it’s revenue-producing—you should probably keep it in the cloud. The cloud is generally more reliable than individual data centers, and the repatriation itself could easily cause disruptions.

    In addition, the cost of running mission-critical applications is less important simply because they are so essential to the business. If the application is burning money but is also your only source of revenue—unless it’s burning more money than it earns, it probably makes sense to keep things as-is.

    Looking at the Exit

    Of course, depending on your application’s architecture, repatriating it from the cloud to a data center could be either impossible or prohibitively expensive. If the application relies on the cloud provider’s proprietary services—databases, for example, or Lambda functions—moving it off of the cloud is going to be extremely hard. Even if it turns out that moving from the cloud to the data center is possible, it could easily cost so much that it wipes out any potential savings from repatriation.

    This isn’t to say that you should never think about leaving the cloud—in fact, if you think moving cloud workloads back on-premises is something you’d like to do at some point, you should consider it during the architecture phase. The decisions you make at that point will determine how challenging it would be to move off the cloud in the future—or even to change clouds if you want to. Using Lambda is going to make moving off the cloud very difficult, for example, whereas using containers will make it comparatively easier.

    When we talk about the costs of public clouds versus data centers, we’re trying to compare things that are fundamentally different. First of all, public cloud costs are notoriously difficult to understand, whereas understanding the costs for on-premises is relatively easy. Sure, there is overhead—building, staff members, etc — but it’s not that different from calculating any other cost in a business and an accountant could make sense of it in 10 minutes with Excel. Good luck doing that with AWS.

    That’s the core problem with cloud costs—humans have a hard time trusting what they don’t understand. But cloud has never been about reducing costs. And regardless, the cheapest option is not always the best option.

  • Stop Hiding the Cloud From Your Developers

    Stop Hiding the Cloud From Your Developers

    If you say a person or organization “goes to great lengths” to achieve something, it means they try very hard and perhaps do extreme things to accomplish their goal. One example I’ve seen is that of more traditional companies “going to great lengths” to “hide” the cloud from their pool of potential technical consumers doing work like development. Instead of saying, “Here it is,” they block or restrict users from direct consumption. Under this model, developers don’t directly login to Azure or AWS, they go to the “internal corporate portal” and fill out a request form for the resources they want and submit it. Then, someone eventually processes the request and creates what is needed.

    In extreme cases, organizations create “cloud teams” and staff those groups with people who build cloud resources on behalf of downstream technical consumers, like developers. Potential consumers must submit a request with a detailed design document specifying everything they want. Then, the cloud team schedules the project and delivers it at a future point. The whole process mimics the historical waterfall approach to software development or systems implementation.

    Why do things this way? It always seems to come down to four distinct drivers:

    Costs: “If we give open access, we will end up with a huge bill!”
    Compliance: “Everything built must meet our security standards.”
    Complexity: “Most users will waste time trying to figure it out.”
    Control: “Our group has always coordinated access to resources.”

    In traditional companies, the reasons for this restricted access always seem to be some variation of those on the list. And when you rebut with something like “Do you think Facebook, Twilio, Netflix, etc. restrict their developers’ cloud access?” the answer is usually something like, “Well, those are elite tech companies; we’ve always done it the way we do it now …”

    In most cases, there is no singular argument you can make to change someone’s mind, or expand the range of possibilities. But you can offer facts. So, let’s take on their arguments one at a time and see if we can rebut them.

    Costs

    Argument: “If we open up the cloud to everyone, then all the developers will endlessly create virtual machines (VMs) and associated resources and services, and we will end up with a huge bill.”

    Rebuttal: There are certainly examples of this; do a search for some variation of “unexpected cloud costs,” and they’ll pop up, especially from a few years ago when cloud adoption was just taking off. But what about today? What can be done to control costs? Even though there are lots of tips and ideas on how to control cloud costs, I’ll offer one simple possibility that directly applies to developers and development groups that is not often mentioned in many articles: implement a cloud resource quota per developer or dev group.

    In AWS, for example, you can allocate via IAM; with Azure, you can use resource groups. The upshot is that there is a way to restrict the number and amount of resources that a single user can consume. So, whether you have 10 or 1,000 developers, you can use these built-in mechanisms to limit and then estimate what your consumption will be. If I have 100 developers and I put a limit on the number of VMs, the number of GB of RAM they can allocate and the amount of storage each developer can consume, then haven’t I just created a “cap” on consumption? The quota concept gives you a path to a “predictable” bill every month.

    Compliance

    Argument: “If we open up access to everyone, they’ll create VMs that don’t adhere to all our internal security standards.”

    Rebuttal: Aren’t developers just looking for a VM (or VMs) to do dev work? We aren’t talking about building production-hardened VMs to host applications. We are talking about giving developers the proper sandbox in which to do their work. So, from this perspective, requiring that developers only create VMs that adhere to strict compliance standards reserved for production servers doesn’t make sense.

    For example, maybe one of your compliance standards is that all production servers have a monitoring agent installed on them. Fine, that makes sense; what about dev/test? In dev/test, I might be spinning up a VM or a container that only exists for a short time, maybe even less than an hour while some tests are running. Does it make sense to require that a monitoring agent be installed on a VM that will only have a one-hour shelf life? Just throwing out the term “compliance” as a catch-all is not a real solid objection. Perhaps for dev/test, there are minimum standards you would want to follow regarding OS levels, patches, etc., but the VM(s) you use in dev/test do(es)n’t necessarily need to have all the additional security requirements reserved for production servers.

    The other part of this objection we hinted at earlier is that you have to transition to “cloud thinking.” Resources that exist for the next 10 minutes in the cloud could intentionally be gone shortly after that. In the cloud, you can quickly create and destroy VMs, or entire environments of VMs. That is what makes the cloud a game-changer versus traditional on-premises methods. You can’t apply the same on-premises considerations to the cloud one-to-one. You need to come up with a new thinking model that takes into account what it means to use the cloud versus how you did it before on-premises.

    Complexity

    Argument: “It’s too hard to figure out some of these cloud architectures, and developers will waste time trying to do so versus having a central team do all the work correctly the first time.”

    Rebuttal: Without the commitment to being a “learning organization,” there can be no DevOps, no transition/migration to the cloud, no digital transformation. Check out item number six on this list of 7 Ways to Make Developers Happy. (Spoiler alert: it’s ‘promote continuous learning.’)

    If “complexity of learning” is one reason why you restrict your teams’ access to the cloud, then you are missing the point of what it means to be a technical expert. Developers partially define themselves by the depth and the range of knowledge that they have accumulated, so continuous learning is a significant component of keeping developers “happy.” Not to mention that happy developers are more engaged and tend to stick around longer at companies that keep them that way; you’re risking losing the technical talent you do have, which has a host of detriments to your organization.

    Control

    Argument: “If developers are creating their own servers, what does our team do?”

    Rebuttal: This one is the toughest of all to rebut. Many organizations have one or more infrastructure teams who are responsible for creating servers and resources and giving access to downstream consumers. These groups control the resources. Now, along comes the cloud where everything can be self-service. And the natural reaction is, “If developers are creating on their own, what do we do?”

    For many traditional companies making the transition to the cloud, there will still be many opportunities for participation. Instead of “architect,” now we need “cloud architect.” Instead of “engineer,” now we need “cloud engineer.” Also, what other higher-value work could you be doing for the company if you weren’t spending all your time provisioning and maintaining on-premises servers? Do you think all of the existing on-premises applications are going to go away overnight? Will your company become “cloud-native” in the next six months? What about all of the AIX, IBMi, Solaris and other legacy components that are in the data center? There will always be plenty of work for everyone to do. And it’s always an opportunity to learn some new skills.

    The reality is that giving developers direct access to the cloud (with controls) frees up many other corporate resources to work on things that are, strategically, more important. If your company is not cloud-native right now, then guess what? It won’t be for a long time. Maybe in the short term, you’ll be hybrid-cloud and then in the long term, cloud-native. Along the way, there will be opportunities for everyone to rethink how things get done and maybe learn something new along the way.

    If you are hiding the cloud from your internal customers, ask yourself, “Why?” Are the original reasons still relevant, or are they holdovers from a time long past? Maybe it is time to re-examine your original rationale for why developers don’t have direct access to the cloud. If the goal of your organization is to “service the customer,” “do more,” “move faster,” etc., then removing internal barriers to accessing the cloud is one way to make progress.

  • After the Turning Point

    After the Turning Point

  • The Move Away from Monolithic Application Development

    The Move Away from Monolithic Application Development

    Shifting from monolithic application development

    Businesses need agility to deliver better services, meet changing requirements, and seize new opportunities as they arise. At the heart of many efforts are applications based on modern development strategies and techniques. Specifically, many businesses are moving away from monolithic applications of the past that are hard to modify and take a long time to bring to market.

    Why the shift and why now? Over 80% of organizations expect to compete mainly based on customer experience (CX). As a result, businesses in the most competitive markets like retail, banking, insurance, financial services, and travel/hospitality cannot afford to wait months or years to release new services, applications, or features.

    The bottom line is that software development teams are under pressure to deliver more of everything (new applications, enhanced features, more access options) in shorter time frames. A widely cited past industry study put the issues into perspective. Leading companies routinely perform multiple deployments daily. By comparison, low performers reported deploying only once a month at best. (At the extreme end of the spectrum, companies like Amazon and Google do deployments thousands of times a day.)

    Monolithic application development does not work in this fast-paced environment. A simple change in an existing application, such as incorporating a new dataset, adding new features in a front-end app, or using a different analytics method, requires that the entire application be revised, retested, and redeployed. That all takes time. Lots of time.

    A better approach is to use modern applications development methodologies. In particular, there is a shift underway to using cloud-native architectures based on loosely connected microservices and elements.

    A cloud-native approach is particularly well-suited for modern applications for several reasons. For example, a cloud-native approach helps organizations address the customer experience drivers that require constant updates and new services. Each component of a cloud-native application can be deployed and maintained as a self-contained microservice. If any element of a broad application needs to be updated or changed, only that element needs to be touched. The rest of the conglomerate application remains the same.

    z/OS plays well with cloud-native

    Many industries under the greatest pressure to speed development and deliver ever-more customized, personalized customer experiences use z/OS systems. As noted, these are retail, banking, insurance, financial services, and travel/hospitality. Government also can be added to the list. It is a large user of z/OS systems and is constantly trying to improve access to its services via new or improved web, mobile, chat, social, and phone applications.

    There are two ways to enhance and develop applications for these systems that use modern development methods. One is to make data, applications, and services that run on z/OS systems available as APIs and as microservices to be used by larger cloud-native applications.

    The other method that is gaining more favor is to provide the modern development tools for the z/OS systems themselves. Specifically, modern application development approaches that move away from monolithic architectures need certain essential elements. Many rely on open-source development techniques, workflow automation, and continuous integration and continuous delivery (CI/CD) tools.

    Bringing such commonly used tools to the z/OS environment helps businesses speed the development of new applications to meet changing demands of their customers. It allows a business to leverage the data and applications on its z/OS systems and create innovative new applications.

    In an age when it is getting harder to find developers with expertise in native z/OS programming, bringing familiar DevOps tools to the z/OS environment offers several benefits. Those who have the native z/OS skills can focus on core applications and leave the tasks like supporting a new front end or enhancing a web interface to others. After all, there are many more developers available with modern development skills.

    Bringing the DevOps tools into the z/OS environment also lets businesses retain all the pluses of those systems. Namely, businesses are assured that the same reliability, superior performance, tightly controlled security, and massive scalability are retained and can be leveraged with integrated with a broader cloud-native application.