devopsy.kinsta.cloud

Author: Liran Haimovitch

  • 5 Myths About Software Development

    5 Myths About Software Development

    2020 has broken many rules about software development. Some perceived trends, however, remain myths

    Some trends come and go, some trends stick. I remember when Docker launched and it was barely mature enough to run unit tests, and now containers are a common way for modern orgs to deploy applications. We’ve seen the rise of microservices but also the return to the monolith. We’ve seen “observability” take off in popularity, while serverless remains a buzzword with limited (but fast-growing!) adoption. Machine learning and artificial intelligence are still click-worthy headlines, but how much actual ML is being used within our applications?

    The True State of Software Development

    Let’s look at five common myths about the current state of software development and evaluate why they’re not completely true:

    Digital Transformation Initiatives Will Be Hindered by the Pandemic

    We live in an online world where every business is already a software business (or rapidly becoming one). The impact of the pandemic further highlighted ISG’s research which stated that “2020 will still see the rapid scaling of digital initiatives across industries.” While some industries have been hit so hard that digital projects had no choice but to stop (e.g. the airline industry), in many circumstances this will be the catalyst to fully embrace digital transformation.

    The Waterfall Method Still Works

    Organizations that haven’t adopted more agile and iterative approaches to building software are operating at a significant disadvantage. I know there are many big companies that still believe in doing all of the strategic planning upfront (I know this because I talk to these companies), but the truth is that it leaves very little room for flexibility and improvement in real-time. In today’s world, the customers and the users are kings—it is no longer possible to build great products without their input. If you take anything away from this article, it’s that the waterfall methodology needs to be abandoned once and for all.

    Everyone Loves Kubernetes

    K8s is not a one-size-fits-all solution. The fact of the matter is that a large chunk of the enterprise still hasn’t fully embraced the cloud, let alone started containerizing their applications. So while we have to give credit where it’s due and acknowledge that K8s is the clear leader for orchestrating containers, we also have to acknowledge that the hype doesn’t quite match the adoption. It’s still a relatively young technology.

    According to a report from Datadog last year, 45% of their customers that run containers use Kubernetes. That number is growing and is certainly impressive, but when you realize that only a chunk of their customers run containers in the first place and they are a modern monitoring solution where we’d expect to see a higher percentage than a random sampling, it’s clear that K8s is far from mainstream.

    Everyone Is Doing Tracing

    The rise of the digital age has put monitoring and observability in the forefront. As we rely more and more on online services for internal and external interactions, we better make sure they are working properly. But at the same time, regardless of industry headlines and conference talks focusing on tracing, the truth is that the industry at large has yet to adopt it.

    For most organizations, there’s so much room for improvement in getting logging and metrics right, that there’s no need to opt for tracing (yet). After all, Google built most of its global platform relying on metrics. Unlike SREs, developers often find tracing alien and very cumbersome to deploy and wield. Instead, more and more companies are opting to empower their engineers to see what’s going on in remote environments through software understandability.

    AI Will Solve Our IT Problems

    We’ve been hearing about the promises of AI in IT for a long time now. One of the terms still actively promoted that I am very skeptical of is “AIOps.” What does that even mean, really? According to a recent report from OverOps, only a very small percentage of companies are even considering AIOps in their plans for the future.

    That said, I do believe in making better, data-driven decisions. So the more data we can collect, contextualize and understand, the better. We see how this helps companies identify anomalies, alert on issues and even project out into the future. But none of this, really, is artificial intelligence.

    Conclusion

    There’s often a gap between hype and actual adoption. That’s the role of good marketing. And ultimately, hype helps drive adoption. But as technical practitioners, we need to stay rooted in reality in software development and beyond. So while I am convinced agile has proven to be the best way to build and deploy software, and that most organizations would benefit from letting go of old-fashioned waterfall processes; on the other end, I haven’t been fully convinced of the benefits of tracing and AIOps for most companies.

  • Using this Time to Optimize Your Dev Team’s Workflow

    Using this Time to Optimize Your Dev Team’s Workflow

    As Andy Warhol once said, “They always say time changes things, but you actually have to change them yourself.” This more than ever resonates with the change that companies have found themselves experiencing of late. The more the world embraces digital methods of work, the more that change becomes paramount to a successful workflow. It is crucial to adapt, whether that means throwing out the old or bringing in the new — or a mix of both. 

    The current global pandemic has forced companies to reconsider how they operate, and it’s no different for their development teams who now find themselves distributed. So the question becomes: How do you go about using this time as an opportunity to optimize your team’s workflow?

    By making the necessary changes, you can not only increase productivity, but also make your team happier. As the saying goes, “Happy devs, happy life.” Let’s look at automation, independence and understandability as key components of your digital transformation. 

    What’s Killing Your Team’s Productivity 

    The Problem: Too Much Bureaucracy

    Being too dependent on management or your colleagues is often a bottleneck at many companies, especially larger traditional ones. When we were all in offices, this problem could be mitigated more easily — but today, things are shifting toward more ownership, and having everyone distributed means you need to be able to get the job done yourself.

    The Solution: Shift-Left

    Bureaucracy shouldn’t be in place just for bureaucracy’s sake. While the goal of those processes are typically risk mitigation and governance, DevOps advocates have been arguing that modern tools and techniques allow shifting-left much of that burden directly onto developers. Use this time to empower developers to build in alternative safeguards relying on automation, self-service and measurement instead of change boards and forms.

    The Problem: Status Meetings

    Status meetings are the bane of all developers’s lives. Nobody will argue that they’re not important, but who wants to sit through meetings when you can be spending time elsewhere? — for instance, at your desk, sipping a nice cup of coffee while working on your code and finding that elusive bug.

    The Solution: Asynchronous Communications

    What used to be done with lots of in-person status meetings doesn’t always translate well to a video conference — water cooler talk just isn’t the same via teleconference. While it’s important to try and maintain that personal touch, it’s even more important to enable asynchronous communication methods as much as possible — both free-form (such as email) as well as structured (such as ticket management). Moving to this new mode of operation requires developers to be more independent. This is another place where automation can play a huge role, formalizing tribal knowledge into scripts and tools, making them easily accessible for all.

    The Problem: Lack of Data

    How many hours have you spent staring into the great abyss of code, hoping and praying that you’ll be able to deploy soon? You’re not alone, we’ve all been there, done that. Waiting for deployments is par for the course of living life as a dev. The source of this long wait? A small, missing piece of data. And this need for data creates what I like to call the engineer’s dilemma: Is it better to fly slow but have the data I need, or fly fast but perhaps be making worse decisions due to a lack of data?

    The Solution: Understandability

    Understandability tools allow quick access to data in real time. This results in shorter, more efficient workflows, which in turn improves team velocity and code quality substantially. Understandability is not the same thing as observability. Think of it like this: Observability helps teams quickly identify where a problem is, but you still need a tool that can quickly fetch the data in order to solve the problem. In other words, if data is the new oil, go find the understandability tool that you think is the best drill.

    Conclusion

    Change is not a concept most like. But now that it’s happening anyway, it creates an opportunity to introduce a healthier, more productive workflow. Grab that cup of coffee and ask yourself: What change would benefit us most? Find it, implement it and watch as your distributed teams become a smooth-sailing ship in no time.