devopsy.kinsta.cloud

Tag: software developers

  • 5 Key Skills Developers Need to Master in Order to Thrive

    5 Key Skills Developers Need to Master in Order to Thrive

    The promise of the cloud, in its essence, allows the IT department to focus on generating business value rather than spinning cycles fixing and managing infrastructure. However, the cloud is not a one-size-fits-all proposition, and many early adopters are finding it challenging to move to the cloud. There are well-documented cases of huge budget overruns, far in excess of prior on-premises costs, making estimating costs in the cloud versus the status quo a key skill of any C-level IT executive nowadays.

    This has ushered in an era of microservices and cloud-native applications. The symbiotic relationship between the two has enabled new architectural patterns such as microservices, while the cloud itself has enabled cheap experimentation and throwaway infrastructure. This means developers today can focus less on the infrastructure itself and more on dedicating additional resources, time and skills to iterating and deploying new code, which was traditionally only available to big organizations with limitless budgets. In addition, this evolution has created opportunities for a crop of new developers who come from non-traditional IT backgrounds to supplement the tech skills gap that’s currently crippling the industry.

    Here are five invaluable skills I believe every developer, whether just entering the workforce or currently in it, should cultivate.

    Adaptability Is Key

    This goes without saying, but developers today must be polyglots. Ten years ago, a developer would only have to reason about one process, in one language, connecting to a database. Today, with the advent of microservices, there are many different stores of data and many applications, written in many languages, that all need to coordinate with each other over the network.

    Different development teams are generally responsible for their own microservices, which in turn interact with other teams’ microservices. Careful thought is required when designing APIs through which they interact. Backward compatibility, availability and graceful failure all become crucial design decisions.

    More than ever, adaptability is a key skill. In the past, developers might only have needed to learn one language and one database, and chances are that skill set would have been all they needed throughout their entire career. Today’s developer will know Java (which is still by far the most popular back-end language), but the rise in newcomers such as Go is driving the development of a new wave of cloud-native software, such as Kubernetes and Docker. It’s critical that developers keep up with new languages and database technologies.

    Communication Is Critical

    Communication is vital. Traditionally, developers have not been known for their communication skills, but with distributed teams and developers working from home becoming more common, working in isolation is no longer an option.

    Because of these changes, it’s easy for a developer to become overwhelmed, which is why it’s also important to learn how to schedule time and how to be able to look after oneself physically. Taking breaks, sleeping well and exercising regularly is vital to preventing burnouts.

    Always Look for Ways to Improve Your Technical Skills

    It’s now easier than ever to improve your technical skills. The most important technologies are open source, meaning you can download everything you need and learn at your own pace. Many online videos and other materials can be leveraged as well; you no longer have to wait for your employer to approve funding for training.

    But crucially, the easiest way to pick up technical skills is to practice them in a business setting. This may mean moving jobs to find the right fit. Another way to become familiar with how distributed teams work is to contribute to an open source project. You can contribute to these projects in many different areas, not just coding. Contributing to documentation, for example, is an area that offers a low barrier to entry.

    Success in Humility

    There are certain traits I always look for when building development teams. First and foremost, I always look for people who are able to clearly express ideas and cooperate with other members of the team.

    Humility is a key requirement, because teams that cannot come to a consensus are doomed to failure. It is no use having an intransigent individual who will insist his or her ideas are best; you will waste many hours coming to conclusions with such people. Quite often, hiring a rocket scientist into your team can upset the entire balance.

    Don’t Be Afraid to Ask Questions

    One particular incident very early on in my career demonstrated another key skill: Never be afraid to ask questions, even if it is the same question you’ve asked previously. At the time, I was working as a mainframe operator for a book sales company. All of the day’s orders were stored in volatile memory; at the end of the day, they would be applied to a batch process that would calculate stock, print invoices and send instructions to the warehouse for customer book deliveries. This was in the time before the internet, so orders were entered manually by the data entry team who worked through order forms sent in the mail. Approximately five people entered these orders, and they usually totaled around 100-200 a day.

    I was working on overseeing the batch process that night and was a few weeks into the job. There was an initial step in the batch where manual input was required to start it. However, I encountered an error message and it offered a number of options with increasingly cryptic descriptions. I had no idea which option to choose. Rather than ask the senior person working with me, I simply made a guess. The option I chose ended up wiping the volatile memory holding all the day’s orders. While this caused the company to lose a significant amount of money, I learned a vital lesson: Never, ever guess and always ask for help.

    Developers are today’s innovators. With the advent of the cloud, concerns around infrastructure are minimized. In most cases, platforms to run an organization’s business software will already be available. The days of a developer having to worry about selecting a database and working out sizes of servers will be gone. Instead, a developer’s key skill will be in writing the business software and identifying which cloud platforms to use in order to deliver it. Armed with that knowledge and the desire to keep learning, today’s new wave of developers will only become more adept at delivering value over existing business processes.

    — David Brimley

  • How App Stores Are Addressing Fragmentation in the Linux Ecosystem

    How App Stores Are Addressing Fragmentation in the Linux Ecosystem

    According to DistroWatch, 273 Linux distributions are currently active, with another 56 dormant and 521 discontinued. While some of these have shared underpinnings, it still makes for an extremely varied landscape for companies and developers.

    It means developers must create multiple versions of their applications to be able to provide their software to all Linux users or just address a fraction of the market. Also, developers require multiple versions of build tools, which inevitably results in significant resource overhead.

    Desktop application distribution is complex across all operating systems in general; in Linux, this is further compounded by such fragmentation and inter-dependencies both in the packaging and distribution of software.

    For example, Fedora uses the RPM packaging format, while Debian uses the .deb format. Moreover, packages built for one version of a Linux distribution are often incompatible with other versions of the same distribution and need to be built for each version separately.

    Developers need to satisfy all these requirements at the same time to be able to successfully offer their products to their users, which can be difficult with limited resources.

    In a way, the choice of distribution and subsequent promotion of Linux software is a chicken-and-egg problem. Initially, companies and developers must decide what parts of the Linux desktop system they want to target. Then, once they have their products available to end users through one or more of the distribution channels, they still have to invest in separate efforts to promote their applications and capture usage.

    Unfortunately, there is insufficient data to assist in the selection and optimization of either the distribution or the promotion process. Linux software developers generally lack sufficient immediate visibility to the usage and popularity of their software.

    Traditionally, there have been multiple dimensions to how creators distribute their software: official websites, where companies and developers offer software downloads on their own domains; code repositories such as GitHub, GitLab and SourceForge; and application repositories in which Linux-based operating systems typically provide software through self-hosted storage locations.

    To achieve the highest level of penetration, software developers will often distribute their applications using some or all of the above methods. Likewise, most users will utilize multiple methods to obtain software they need. While this gives developers more freedom in how they deliver applications to the end-users, it creates additional fragmentation.

    In recent years, there has been significant effort to address the fragmentation in packaging and simplify the distribution of software through the establishment of software centers, in which some Linux distributions offer store-like destinations with a graphical frontend, software ratings, screenshots, descriptions and other user-focused data that allows better search and discovery.

    Currently, there are three of these in the Linux space—AppImage, Flatpak and snaps. They each approach and handle the various aspects of usability in different ways.

    AppImage and Flatpak technologies are architected to primarily support GUI desktop applications. Snaps are designed to work with servers, cloud infrastructure and IoT devices, in addition to desktop applications.

    Spotify, a snaps publisher, is an example of a company benefiting from this approach. On one hand, it requires the Spotify engineering team to maintain both the snap and the traditional Deb package. On the other, the snap version is significantly easier to release, which has also helped with the simplification of the Deb release, as well.

    The primary reason is the ability to use easy rollbacks, which have already been used. This feature removes uncertainty that a possibly broken version of the Linux desktop client application might be pushed out to the users. Spotify engineers first release the snap version, and after ascertaining that it works and behaves correctly, they build the Debian package, too. Snaps allows the Spotify team to more closely follow the weekly cadence of releases they have for the Windows and Mac versions.

    The emergence of self-contained packaging and distribution mechanisms addresses a major problem in the Linux application ecosystem–the difficulty in establishing a successful business model because of the packaging and distribution challenges. The new formats reduce the fragmentation, as they minimize the number of permutations developers need to support for their applications.

    The shift toward centralized application stores that are not specific to any particular Linux distribution offers higher discoverability and better consistency in the user experience.

    Developers need fewer resources to support multiple target platforms, which allows them to focus their efforts on the core product, with the understanding their software will be available to the wider desktop audience, without having to depend on distribution-specific dependencies.

    Since the aspects of new, refined models of promotion and distribution in Linux are still relatively young, we see improvements but there is still opportunity to develop and adopt better, data-driven practices.

    As this field continues to evolve, the store model will help drive growth and usage of the Linux desktop, offering software developers a refined, more tangible experience than ever before.

    — Martin Wimpress

  • Better Together: Why Software-Development Toolmakers Should Embrace Integration

    Better Together: Why Software-Development Toolmakers Should Embrace Integration

    It’s getting harder for businesses that are building technology tools to get attention, traction and ultimately widespread adoption. You can’t just launch an amazing new developer tool and hope developers will find you; providers need to zero in on a specific use case that empowers developers while also ensuring those developers will still have access to the broad ecosystem of other tools they need to do their jobs.

    The more forward-thinking companies in enterprise SaaS, public cloud computing and artificial intelligence are increasingly partnering with companies they might once have considered competitors to elevate the presence of all their brands among end users. By meeting in the middle, and integrating with a common-ground platform, providers join their customers where they are, on the platform that makes the most sense for them.

    Instead of forcing customers to choose, providers can take advantage of powerful network effects, where their tools become more valuable because they’re part of a network. It’s one of the oldest concepts in computing: Metcalfe’s Law states the value of a network is equal to the square of the number of users on that network.

    But building that network yourself can be time-consuming and costly, as many of those who’ve done it alone have discovered. That construction project can easily distract providers from their own core competencies, forcing them to spend time and resources on essential but undifferentiated development work.

    Network Effects

    The mobile side of tech has been operating under these principles since the launch of distribution platforms such as the App Store and Google Play, which introduced mobile developers to millions of potential customers. Those customers want seamless connections between their favorite apps and services to streamline their digital lives. They don’t want every app developer to create their own marketplace with incompatible payment methods, unfamiliar interfaces or strange hoops to jump through.

    The explosion of enterprise software vendors enabled by cloud computing and software-as-a-service models has created similar patterns. Cloud-native developers have embraced distribution channels such as the AWS Marketplace as the best way to find their customers, and enterprise companies such as Box and Dropbox are making integrations with rival products and office productivity tools (like G Suite or Office 365) an important part of their product strategies.

    “What seemed unfathomable merely a decade ago is now becoming commonplace as Fortune 500 companies are mixing and matching best-in-class technologies—from upstarts to cloud mainstays like Salesforce, Workday and ServiceNow—to power their business,” said Aaron Levie, Box CEO.

    But the work required to enable those integrations is substantial.

    Growing companies focused on building best-in-class tools for developers don’t always have the in-house expertise required to strike partnership deals with platforms and support customers with a world-class billing system. Likewise, end users often need to do their own due diligence when considering whether or not a promising new development tool will play nicely with their existing tech infrastructure.

    Go to Market

    Marketplaces are the best way to solve these problems. Service providers need distribution and integration with other development tools to reach end users, and end users want the peace of mind of knowing they’ll be able to properly evaluate a tool under consideration through a certified clearinghouse.

    Companies can certainly build API-level integrations on their own for one-off partnerships or integrations where performance isn’t a major requirement. However, when performance is vital, such as with databases or infrastructure monitoring tools, a more deft touch is required.

    These seamless, low-latency connections are only going to become more important in a multi-cloud world as companies use the power and scale of Kubernetes to build tech infrastructure that spans several different cloud providers and perhaps even their own on-premises servers. True service interoperability will require common frameworks to make sense of all those connections and allow developers to mix and match their favorite tools to create the technology stacks of the future.

    Enterprise software silos are a thing of the past. The future of software development will rely on tools that blend the best available services—no matter where they were born—and link developers, service providers and platform companies in flexible and dependable ways.

    The companies that figure out how to integrate best-of-breed software development tools with the leading platforms and services of our time will win. If you’re just starting out, let someone else handle the complexities of integration and distribution while you focus on creating the best developer tool you can.

    — Jevon MacDonald

  • Portable Security Policies: A DevSecOps Primer

    Portable Security Policies: A DevSecOps Primer

    Protecting critical data and applications is a challenge under any circumstances, but it’s especially daunting when resources reside in the cloud. Most organizations today operate a significant portion of their workloads in the cloud, which adds to the complexity of the security problem—a security team can’t fully control cloud environments but is responsible for securing workloads and applications running there.

    Cybercriminals are exploiting the situation. They’re becoming more aggressive and ingenious in their efforts, taking advantage of the fact that there is confusion about who is responsible for which aspects of security under the Shared Responsibility Model. Adding to the chaos is the differentiation between cloud providers’ security offerings and capabilities. Quite simply, in most cases, cloud providers are responsible for the security of the cloud and consumers are responsible for security in the cloud, meaning that security and networking teams still need to ensure their organizations’ workloads and applications are free from malware or other tampering.

    To accomplish this, security and networking teams can’t rely solely on firewalls, threat detection and vulnerability patching to secure vital digital assets. Security tools developed for traditional data centers are not effective at securing workloads in the cloud due to the cloud’s dynamic nature. Security and networking teams must rethink their approach.

    Unfortunately, many organizations are still relying on old and ineffective strategies—further hardening the perimeter, investing in additional threat detection and adding new tools and controls that focus on identification rather than prevention. This security approach has its place, but it does nothing to prevent malicious actors from moving laterally across the network once they achieve a foothold, which leaves cloud-hosted apps and workloads extremely vulnerable.

    Instead, security teams need to enable zero trust in cloud environments, which treats all internal communications as untrusted by default. With zero trust, only authorized applications and services are allowed to send and receive communications, and only in specific ways governed by the principle of least privilege.

    The Second Layer

    Traditional tools aren’t effective in enabling zero trust in the cloud because security and ops teams have a very limited ability to manage all layers of the cloud’s open systems interconnection (OSI) model. Specifically, the lack of Layer 2 controls in infrastructure-as-a-service (IaaS) environments makes tools developed for discrete networks all but useless for locking down ports and controlling or scrutinizing IP addresses.

    Even if an organization manages to implement these tools in the cloud, it cannot provide the level of granularity required to stop malicious lateral movement. For example, when on-premises tools are repurposed for cloud environments, they usually rely on subnets to define the boundaries of communication. Because cloud subnets are designed to handle elastic workloads, they need to be far larger than those in on-premises environments. As a result, cloud workloads are more exposed than is necessary.

    Securely migrating workloads and applications to a cloud environment is a huge and cumbersome job when relying on traditional tooling. The best way to make workloads portable and secure is to decouple workload protection from the underlying infrastructure. In this way, organizations can be certain that any policies applied on-premises can migrate to the untrusted environment of the cloud, without the complexity of mapping changing network addresses, writing policy exceptions or losing fine-grained control during the process.

    Decoupling workload protection from the network requires abandoning a network address-based approach in favor of one based on identity. By using the immutable properties of workloads, security teams can create cryptographic identities for applications and services, which then can be used to determine what is allowed to send and receive communications. Not only does this model provide stronger security, but it also works regardless of where applications are located, because these identities are unaffected when network elements change. What’s more, they can be constructed to tolerate upgrades. By building identity-based policies, security teams can create microperimeters around applications that follow workloads wherever they go, and the policies verify communication across boundaries every time an application attempts to communicate.

    Implementing network-agnostic policies doesn’t just harden security. Software developers benefit as well. Without the roadblock of translating application-speak to network-speak, developers can build software and applications in any environment favorable to their workflow while defining policies to protect their work. Once the software is built, they can securely deploy the finished product to the production environment—even if it is hosted by a third party.

    No organization should have to compromise security to benefit from the efficiencies offered by the cloud and ephemeral auto-scaling containers. Building identity-based policies that enable zero trust and are independent of the underlying network ensures that companies never have to consider making that trade-off.

    — Tom Hickman