devopsy.kinsta.cloud

Tag: custom software development

  • Tabnine, GitLab Build Custom Apps Faster With AI

    Tabnine, GitLab Build Custom Apps Faster With AI

    Tabnine today revealed it has integrated its code completion tool with the GitLab continuous integration/continuous delivery (CI/CD) platform. Tabnine’s platform employs artificial intelligence (AI) to accelerate application development.

    Brandon Jung, vice president of ecosystems and business development at Tabnine, said the goal is to make it easier for developers to automatically write code based on custom models created using AI. Those models would reside in the CI/CD platform provided by GitLab. Developers can now create custom models of their private source code, he noted.

    The Tabnine AI assistant can then be trained on a customer’s private code, style and security best practices that have been defined by an internal DevOps team, added Jung. That assistant, accessible from within a developer’s integrated development environment (IDE), is conversant in 35 programming languages.

    The code completion tool doesn’t eliminate the need for developers to write code; instead, it completes code once developers start writing it based on the model stored in the CI/CD platform.

    Nima Badiey, vice president of global alliances for GitLab, said the overall goal is to increase developer productivity at a time when organizations are launching more application development initiatives than ever. Many of those applications are being constructed using multiple programming languages that each individual developer may not have equally mastered.

    In addition, an AI model will, over time, improve the quality of the code being created, noted Badiey. That should make it easier to review code that is more accurate because it was created with the aid of a machine, he added.

    In general, GitLab has been moving to incorporate AI within DevOps workflows. The company last year acquired UnReview, a provider of a tool that uses machine learning algorithms to identify which code reviewers to assign to a project based on both the quality of their previous efforts and their current workloads.

    It’s not clear to what degree AI will be pervasively embedded within DevOps workflows. However, it’s now just a matter of time before algorithms are more widely employed. Organizations that employ DevOps today devote significant resources to maintaining platforms that could be simpler to manage if more tasks and processes were automated. In theory, more resources could be then devoted to building applications versus maintaining DevOps platforms.

    One way or another, more organizations are moving to increase developer productivity. Developers are both hard to find and retain, so organizations have a vested interest in finding ways to increase the rate at which an existing pool of developers can build applications capable of driving a wider range of digital business transformation initiatives. Of course, an increase in the rate at which applications are developed also has significant implications for the rate at which they might need to be deployed.

    Not everyone in IT is, of course, entirely comfortable with AI. Nevertheless, most DevOps organizations are highly committed to automating as many processes as possible. The only thing that will be different going forward is determining to what degree those processes will be automated by humans versus a machine.

  • Best Practices to Improve your Engineering Sprints

    Best Practices to Improve your Engineering Sprints

    What is the purpose of sprints? We break work into sprints so we can more easily monitor, estimate and predict what we want to ship and when. Over the years, engineering teams have gotten used to moving quickly from one sprint to the next, but I think it’s important to be more thoughtful in how we plan and execute sprints.

    Running effective and successful sprints can define whether or not your organization is able to ship high-quality software fast and often. It also gives teams more flexibility and the ability to quickly change something that is not working or, on the other hand, to iterate on a successful technology. 

    After almost 20 years as an engineer, manager and as a CTO, I have found there are several best practices that improve the sprints that are part of my team’s software development life cycle. 

    Sprint Planning

    When planning a sprint, there are several things to keep in mind.

    Make Sure the Work Aligns with Business Priorities

    There are always a number of elements an engineering team can focus on during any given sprint. It’s fairly easy to lose sight of the business’ end goal. Make sure to gut-check to make sure that the sprint goals align with current business priorities.

    Ensure the Workload is Balanced From the Start

    This seems like an obvious statement, but make sure team members have equivalent workloads so you avoid burnout. It is also important to understand how different engineers on the team work—some people work best by selecting their own tasks with items that are unassigned, some pick up unfinished tasks as they finish others and some prefer to be assigned certain tasks because they have specialized skills. 

    Don’t Underestimate the Time That Interruptions/Additions Take 

    Along the same lines as the above, don’t overlook this for several reasons. Without adequate, data-driven insight into the actual state of each team member’s workload, it is almost impossible to gauge what’s happening in real-time. While business-critical sprints are assumed to take priority, side projects, Slack interruptions and meetings can easily consume an engineer’s day. Make sure to proactively check that each member has enough true deep work time without becoming burned out. 

    Don’t Underestimate the Time it Takes to get Things to a Done State

    Sometimes engineering teams only look at the development stage, but the full cycle required for the software to get to the end user might take longer. Allotting the right amount of time to get the job done across all phases of development will help avoid unexpected surprises. 

    When You Get to Mid-Sprint

    Monitor Unplanned Work

    Initial planning doesn’t necessarily take into account the bugs and fire drills that will likely arise after the sprint starts. Pay close attention to any mid-sprint additions and adjust as necessary. There may be team members who have cleared their sprint queue and are capable of taking on this work, but being aware of team members’ workloads at every stage is critical. 

    Do Daily Stand-Ups and Raise Flags as Early as Possible

    This will help anyone encountering roadblocks so a small issue doesn’t turn into a huge bottleneck. If you look closely at your PR cycle time, you will find a ton of insights about where roadblocks often happen. Using historical data during sprints can also go a long way toward helping identify potential bottlenecks, allowing you to proactively avoid friction by delegating reviews or setting out additional time for approvals. 

    Get Ahead of Burnout

    The tech industry has a turnover rate of 13.2%—pretty high when compared to other sectors. But the reality is that it can be really difficult to identify burnout without hard data. Don’t wait until people start speaking out about being overworked: Burnout prevention should be a full-time focus. Before sprints, make sure people aren’t coming in with high levels of fatigue and make sure that overtime doesn’t routinely increase throughout.

    Use Sprint Progress Estimations to Reprioritize

    Each sprint starts off with a set workload, but in reality, every sprint is dynamic. Take a look at each day’s progress and evaluate if your team is ahead of or behind schedule. If you are on track to finish a majority of the work, you can anticipate a successful sprint end. If not, don’t worry; you can always recommend that your team recalculate priorities. Engineering managers can take this time to load-balance some of the heavier work and shift goals to the next sprint as needed. Staying flexible while maintaining a clear view of what is actually happening during the sprint, will inevitably result in success. 

    At the End of the Sprint

    Do a Thorough Sprint Retrospective 

    As a team leader, you should constantly be thinking about how things are going and how people are feeling. If you can, use hard data to look at things like time allocation, PR throughput and any items added mid-sprint. Taking notes throughout the sprint will help remind you of any issues that came up, and you can discuss ways to improve for next time. Each sprint is a chance to learn; the more you learn, the better the sprint and the better the product will be for end users. 

  • The Lego Approach to Overcoming the Developer Divide

    The Lego Approach to Overcoming the Developer Divide

    As end-user demand for new services continues to rise and businesses adapt to changing times, digitalization has never been more important. Pressure is increasing on organizations to deliver digital transformation initiatives more quickly as 55% of CIOs in 2021 said they were increasing staff to accelerate their digital programs. The cloud is essential for this. Because it can enable new opportunities for revenue and quicker delivery to market, the cloud is the way forward for companies that want digital success. That’s why 95% of those surveyed by Accenture say they’ve adopted advanced cloud services. 

    However, this is not without its challenges. For one, teams need the skills to match—individuals who know how cloud works and the expertise to unlock its potential. But this is proving difficult as talent remains hard to recruit (a recent Gartner report found that IT executives view the talent shortage as the most significant barrier to deploying cloud, edge computing, automation and other emerging technologies). In addition, as 92% of companies believe DevOps is crucial for revolutionizing their digital strategies, it’s worrying to see a new report from Boston Consulting Group that revealed up to three-quarters of developers are looking to change their jobs within two to three years. 

    This is something enterprises need to address if they wish to accelerate digital transformation programs and take advantage of the emerging cloud technologies that support the growing need for a distributed cloud architecture. Without the required developer expertise, organizations will fail to address end user expectations and fall behind their rivals. 

    A Concrete Problem

    While the shortage of developers was an issue even before the pandemic, the problem is only getting worse due to the increasing need for digital transformation. It is putting more pressure than ever on existing developers and making it difficult for organizations as they struggle to recruit more talent. In fact, research found that pressure on digital architects has more than doubled during the pandemic, with almost 50% saying they are currently under high or extremely high pressure to deliver digital projects.

    This skills shortage is an important issue for companies to consider. It is well-known that the expertise needed to deploy and maintain cloud services differs considerably from what’s needed for on-premises environments. Without those skills, it becomes difficult for IT teams to oversee and understand what is happening with regard to their cloud deployments, and it ultimately hinders organizations from generating new revenue opportunities through increased innovation. Cloud is a whole new world where control and insight are limited, there are new inflexible cost structures to get used to and other departments can easily procure new applications without the IT team’s involvement. However, we still see examples of organizations being tripped up by these differences. 

    Organizations take proactive steps to keep their developers engaged and happy to avoid digital transformation burnout and ensure they make the most out of their cloud deployments.

    One Brick at a Time

    One way enterprises can do this is by embracing a Lego approach to their digital transformation journey. By adopting a composable business strategy, organizations are in the best position possible to remove pressure from developers and drive increased innovation with less need for highly specific technical expertise. 

    When building things with Lego, even if you’re starting without instructions, you don’t need to completely start from scratch—and you can use the same bricks time and time again. Composability, or the notion of building and configuring infrastructure and applications from component parts with well-defined interfaces, means the same is true when developing new digital services. Instead of having to start from scratch each time or write specific code, developers and even business users can quickly innovate new experiences by composing and decomposing existing digital assets and reusing them—just like Lego bricks. In this way, the company is using its existing skillset to the fullest; maximizing the value of its resources and allowing it to concentrate on actually developing new experiences and services.  

    Perhaps most importantly—especially for developers—this means less pressure on development teams, not only because there’s less need to reskill but because composability means they no longer need to worry about managing underlying infrastructure or reconfiguring physical assets like servers, storage and connectivity. Instead, they can manage all assets through a single unified control plane that spans multiple clouds, right through to the edge. 

    Making use of Existing Resources

    As part of this composable approach, enterprises should also examine how they move away from legacy technology, making sure they invest in innovations that leverage their existing in-house developer expertise. For instance, using a database-as-a-service platform that has the same programming language and tools that developers are already used to will accelerate adoption and reduce training costs. 

    The move away from legacy technology won’t just increase value for the money at a time when developers are becoming harder to recruit and budgets are tight. It will, again, also make life easier for developers. Instead of having to struggle with the integration of older systems with newer innovations, next-generation technologies will make this process harmonious and easy, further reducing the pressure and speeding up digitalization.

    Creating a Solid Foundation

    The developer divide is an issue that organizations need to take seriously if they wish to drive forward their digital transformation initiatives. At a time when demand for improved end user experiences is high, the need for developers has never been greater.

    While recruitment and retention remain a challenge, the Lego approach of composability means enterprises do not need to lose out. Using the existing skills and resources of a company, composability propels faster innovation and greater agility. 

  • Source Code Management Best Practices

    Source Code Management Best Practices

    Source code is, of course, the foundation of any software development practice. Managing that source code is the first task tackled by modern software development pipelines, with all subsequent stages of the pipeline dependent on the source code for their success and functionality. Thus, it is critical that source code is properly managed without introducing bottlenecks or defects into the delivery pipeline. To do so, there are some best practices to follow when interacting with source code.

    Regularly Commit Changes

    While this may seem obvious, commits often are done sparingly, as most developers tend to commit only after a significant change. The commit frequency depends on the workflow and it is acceptable to commit only after major modifications if that commit triggers another task.

    However, it is better to commit changes—even minor ones—regularly. It not only keeps an auditable history of changes but also enables easy comparisons between commits for troubleshooting and ensures that the code is up to date with the version control system (VCS). However, it does not mean that users should make commits for every small change; instead, adapt a development style that includes frequent commits as part of the workflow. Even if there are many commits, most VSCs provides users with the option to combine multiple commits to a single commit using a rebase for better management.

    Always Ensure That the Repository is Up to Date

    Most of the time, development is a team effort with multiple developers working on a single codebase. Thus, there will be frequent updates to the source code. So it is always advisable to use git pull or fetch to obtain an updated copy of the code before making any changes. This practice not only mitigates merge conflicts but also helps users to avoid errors while pushing the code, such as ‘failed to push some refs to‘ errors which occur when the local copy of the repository is behind the remote.

    Create Detailed Commit Messages

    Commit messages should be meaningful and include the ability for anyone reading the message to grasp the reason behind the commit quickly. It does not mean that users should create lengthy commit messages; instead, they should describe the commit in a concise yet meaningful manner. The commit message should include why the code was committed and not how it can be identified by comparing the files.

    A good commit message can include details such as bug fix ID or requirement ID, which reference the specifications of that code change in project management platforms like Jira and Azure Boards.

    Review Changes Before Committing

    Always make sure to review the code before making commits—this is imperative if you are committing to a shared repository. Typically, code reviews are a part of the delivery pipeline before merging code with the master branch or a specific repository via a review system or a pull request.

    Code reviews put a second set of eyes on code modifications and help detect any issues in the code. It also acts as a quality control mechanism that helps organically improve the overall code quality while helping to increase the awareness of each code change.

    Implement a Proper Workflow

    A proper workflow with standardized practices must be implemented across the development team even while using a source code management (SCM) tool. Some considerations for a standardized workflow:

    • Decide on a branching strategy and branching best practices like naming conventions for specific development types. For example, using a prefix to indicate the type of development feature or bugfix
    • Ensure proper use of scopes to decide who has access to each repository
    • Make sure the review workflow includes which users have the final say in the review process and proper authorization to merge the changes.

    A properly defined workflow describes the complete source code management cycle from creating new branches to making changes and, finally, merging the code to the master branch after review. This process helps organizations simplify the overall code management by pushing users to follow a specific workflow. This can also help easily onboard new developers.

    Implement Proper Security Practices

    This practice goes hand-in-hand with proper workflows, as security will be one of the primary considerations when defining the workflow. It should start from developer authentication and authorization, which controls who has access and what areas of the source code they have access to. Additionally, security practices should provide visibility into all the user activities with auditable trails to pinpoint any unusual activity in the source code.

    Security practices coupled with a good backup and disaster recovery strategy are vital for the continuous operation of the development pipeline.

    These best practices can help developers manage their source code securely and efficiently. A properly implemented source code management system will lead to fewer issues in the preceding stages of the pipeline and ensure smoother operation in the long run.

  • The Life and Times of Feature Flags

    The Life and Times of Feature Flags

    A while back, I had the opportunity to look closely at DevSecOps tools (as the market currently defines them). There was a lot to like, and they are moving forward to a “Find all of the vulnerabilities, all of the time” future … Except there will be new vulnerabilities that aren’t as easy to catch once we get there, and our journey will continue.

    More recently, I’ve had the pleasure of diving into application and API protection, which I can’t (actually, I’m not certain if I can or can’t, so won’t) say too much about at this time, but which are also moving forward in a similar direction, if not in a similar manner.

    And as a developer, feature flags have intrigued me since they first appeared.

    Sing the Sesame Street song with me: “One of these things is not like the others.” Feature flags are … a feature.

    When they first hit the scene, it was literally developers writing #if and #ifdef statements in their code to turn bits on and off at compile time. That reminds me of nothing so much as the Seinfeld episode where they’re explaining to network execs what the show is about. “A developer does his job … that’s a product!”

    The market has come a long way since then. But, honestly, I just don’t see these as stand-alone products. Take a look at the breadth of things most products are doing these days—CI/CD tools, either of the two markets I just mentioned or just about any other market in a similar space. Feature flags are still just about “turn this functionality off, turn it back on”. Newer iterations allow this without rebuilding the entire app. But it’s just not up there with the potpourri that current tools markets offer.

    My take is that these tools will end up as part of a larger toolset. Microsoft, Atlassian and Cloudbees (to name the ones I’ve seen without looking too hard) already implement feature flags, shrinking the available market. And they implement them because it’s a perfect fit with several markets. DevOps tools—which is where each of these vendors implements them—are one of the best market fits.

    Which market will end up with them? I have no idea, and that’s part of the fun as an analyst. The best on-the-surface fit would be DevOps toolchain systems like Atlassian offers, where no matter your toolchain, you can use them to speed acceptance testing or save a release without re-releasing. But I can make valid arguments for other locations too, so I guess you all will decide as options come available—decide with your dollars, that is.

    Watch for it. I’m not at all saying “Avoid feature flag companies because it’s not a real product!” I’m just saying that your feature flag vendor is likely to become part of a larger solution at some point, so make sure you have a plan to move off of it in case the larger solution is something your organization just doesn’t want to deal with.

    I am saying, “If you don’t have a feature flag solution—even a homegrown one—in place, it’s time to put one in place. The ability to say “Oh, yeah, that feature is mucking things up, let’s turn it off, quick!” is huge. For larger sub-projects that take multiple sprints, the ability to have the code right in the stream with regular check-ins, but feature-flagged out of the build, is also huge. No merging or other craziness, just “BuildNewFunction=FALSE” in the source or config file. The more advanced the feature flag system in place the better—the newest ones can turn things on and off with an environment variable from a dashboard. This makes feature flag code inclusion far easier and more intuitive than, “Did we account for that database update not happening?” of hand-rolled solutions. Still not perfect—because this is a journey—but store-bought is now better than anything you’re likely to hand-roll.

    And keep rocking it. Feature flags or not, you’re making systems that power the world—or at least your corner of it—and not getting the recognition you deserve. So once again, thank you. For all those people who don’t even know that they should thank you.

  • Best of 2021 – From Agile to DevOps to DevSecOps: The Next Evolution

    Best of 2021 – From Agile to DevOps to DevSecOps: The Next Evolution

    As we close out 2021, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the ninth in our series of the Best of 2021.

    As the workforce shifts to remote locations, networks are becoming more diffuse as the edge gets farther away. At the same time, the number of devices and applications on those networks continues to rise. Some estimates suggest that, by 2030, there will be 15 connected devices for every person on the planet.

    The rapid expansion of the remote workforce and their associated application needs has created a significant challenge for both application developers and the IT professionals tasked with deployment and maintenance of applications. Finding the right balance between speed of release and stability and reliability of applications – never an easy task – is paramount for the success of any organization.

    Agile and DevOps evolved to help organizations strike this balance, providing the best possible customer experience in the shortest realistic time frame. But have Agile and DevOps fulfilled that promise?

    The Promise of the Agile Manifesto

    While Agile as a methodology has been known and followed for nearly two decades, the ways in which organizations have applied Agile have been as varied as the organizations themselves.

    The Agile manifesto set out four basic values when it was first written in 2001:

    • Individuals and interactions take precedence over processes and tools.
    • Working software takes precedence over comprehensive documentation.
    • Customer collaboration takes precedence over contract negotiation.
    • Response to change takes precedence over mindlessly following plans.

    Agile processes are applied across a range of development activities, from development of standalone applications to development of cloud-native business applications. The Agile Manifesto also contains several more principles that further explain what the values mean when put in practice.

    These Agile principles can be condensed into a few areas of focus:

    Prioritize the customer over the product

    Agile development requires continuous customer engagement throughout the entire development process, with the end goal being frequent product delivery based on specific customer feedback. While this can present challenges for an Agile team, particularly when customers demand changes late in the development cycle, Agile maintains that the best way to elevate customer experience is to make the customer part of the development process.

    Trust Agile Teams to Self-Organize and Self-Manage

    Agile focuses on smaller teams that remain in constant communication with customers, as well as with each other. These teams should include both developers and those with knowledge of the larger business requirements being met through development. For these teams to work effectively, trust is key. Agile posits that self-organized teams, given leeway to pursue their projects in the way they see fit, result in the shortest development cycles.

    Keep it Simple

    Agile teams require simplicity. This correlates with Agile’s disdain for overuse of process. Agile seeks to minimize the total amount of work required, thus minimizing overall development time.

    Agility Leads to Agility

    Just as Agile teams continuously improve their product and the customer experience, they also constantly improve themselves. Constant evolution of teams and the processes they employ (remember, teams before processes) improves team agility itself.

    While the Agile values and principles seem simple, effective application of the values and principles is another story entirely. Indeed, at times, the implementation of Agile development has violated the very first value of the manifesto by focusing on which tools and processes should be used. But, in an environment where more users are clamoring for more products and services, implementation of Agile methodologies is not just important, it is imperative.

    Building on Agile with DevOps

    The precise meaning of the term itself and the scope of DevOps remain a source of debate. At a high level, DevOps is the marriage of the development cycle with post-development activities, such as deployment and maintenance.

    According to open source contributor Barbara Ericson of Cloud Defense, “Instead of IT operations and software development being siloed off from each other, DevOps breaks down the traditional boundaries that previously existed between them in order to achieve continuous integration and continuous delivery (CI/CD) of quality software features and applications to end users.”

    Just as with Agile, the effective implementation of DevOps requires cultivating a DevOps culture within the organization. However, Agile and DevOps are also not mutually exclusive. That is to say, DevOps is not merely a replacement for or an evolution of Agile. Although Agile and DevOps differ in their structures and approaches, they can work in unison to achieve the ultimate goals of speedy deployment and enhanced customer experience.

    While Agile and DevOps share common goals, they have not always agreed on how to achieve those goals. DevOps differs in many respects from Agile, but, at its best, DevOps applies Agile methodologies, along with lean manufacturing principles, to speed up software deployment.

    One area of particular tension between Agile and DevOps is that the latter relies heavily on tools; in particular, when it comes to the automation of testing and deployment processes. But DevOps can overcome the resistance of Agile developers to tool usage simply by applying Agile principles themselves.

    Effectively, DevOps proponents must convince Agile teams that dogmatic adherence to the underlying principles of Agile is actually inconsistent with Agile in the first place. Ironically, Agile developers who insist that the process is always bad actually violate Agile principles by refusing to acknowledge the benefits offered through change, another Agile principle.

    The challenge is to have the Agile development teams trust in the automation efforts of DevOps, while at the same time encouraging the DevOps team to consider the business goals of deployment rather than pursuing speed of deployment for its own sake.

    With constant communication between the Agile team and DevOps team (another Agile principle), development can achieve a degree of comfort with DevOps tasks and processes. This means that testing and deployment automation can proceed quickly, resulting in a decreased time to market, overall.

    Ultimately, Agile and DevOps can work together most effectively when they recall their shared goals: smaller change increments based on feedback resulting in faster delivery cycles.

    Continued Evolution: DevSecOps

    As networks expand and businesses continue to integrate cloud-based services (in many cases, building multi-cloud environments), security issues become more and more complex. One area in which Agile is lacking is in integrating security into the development process. Unfortunately, in an Agile environment, application security is often an issue addressed after development, rather than as part of the process. Enter the next iteration of DevOps: DevSecOps.

    DevSecOps revolves around three basic principles: ensuring data security while minimizing inconvenience for users in accessing data, using development tools that identify risks as early as possible in the development process and ensuring data encryption using technologies such as secure sockets layer (SSL) and virtual private networks (VPNs).

    While DevSecOps and Agile may also disagree about the priority of tools, security must become an integral part of any development project. This is why Agile, DevOps and DevSecOps must all work together to ensure not only rapid deployment but secure deployment.

    The Next Evolution

    Agile and DevOps were both important evolutions of the software development process, but DevSecOps is the next evolutionary step. Despite a few disparate characteristics, Agile, DevOps and DevSecOps can and should work in unison to achieve their shared goal: the best possible customer experience and short deployment cycles.

  • Speedscale Makes Free API Observability Tool Available

    Speedscale Makes Free API Observability Tool Available

    Speedscale today announced it is making a free edition of its observability tool for application programming interfaces (APIs) available to developers.

    Ken Ahrens, Speedscale CEO, said the goal is to expose more developers to the company’s API testing tool that can be accessed on their local machine via a command line interface (CLI). Dubbed Speedscale CLI, it is designed to enable individual developers to inspect, detect and map API calls on local applications or containers rather than having to subscribe to the company’s current API testing platform via a software-as-a-service (SaaS) model.

    That approach should reduce the number of disruptions DevOps teams are likely to encounter after an application is deployed in a production environment, noted Ahrens.

    Speedscale CLI features include service mapping, which enables developers to auto-detect and map external dependencies that could break, a traffic viewer for logging and tracing API calls and latency detection tools that show how code changes are impacting performance. In a forthcoming update, Speedscale also plans to include load generation capability to enable developers to run tests locally. The overall goal is to enable IT organizations to shift more responsibility for the management of APIs further left toward the developers that create them, said Ahrens.

    Naturally, Speedscale is also hoping that, as more developers are exposed to its observability platform for APIs, there will be increased demand for its SaaS platform among DevOps teams that need to manage and maintain APIs in production environments within their existing workflows. Speedscale exposes a set of APIs of its own to enable that integration, noted Ahrens.

    At its core, the Speedscale SaaS platform is designed to enable DevOps teams to replay how calls are made between APIs and external mock services to make it easier to diagnose issues.

    In general, there’s a lot more focus these days on APIs, thanks to digital business transformation initiatives that are dependent on APIs to integrate processes. The challenge organizations face is many of those APIs are built by separate development teams. In some instances, organizations can find themselves deploying redundant APIs. Other organizations will create APIs that, over time, are simply forgotten about or that go dormant when the developers that created them leave the organization. These “zombie APIs” often represent a security risk because cybercriminals now routinely scan IT environments for unattended APIs through which they can exfiltrate data without anyone noticing.

    One way or another, the management of APIs is becoming a distinct discipline within many organizations as they come to appreciate the level of IT flexibility they enable. Replacing backend services is a lot simpler when the APIs calls that invoke them both internally and externally remain relatively simple. The challenge is that building and maintaining microservices-based applications based on APIs is a more complex endeavor than building a monolithic application. The first step toward reducing that complexity is, of course, to provide more visibility into the application environment for all concerned.

  • Is TypeScript the New JavaScript?

    Is TypeScript the New JavaScript?

    While JavaScript is frequently the language of choice for all sizes of frontend and backend applications, it’s not the only option; nor is it necessarily the most efficient or cost-effective. Increasingly, TypeScript is becoming the go-to language for app development—particularly for larger apps. The time- and cost-saving benefits are significant enough that some organizations are even taking projects initially started in JavaScript and migrating them to TypeScript. 

    What is TypeScript?

    While the number of programs written in JavaScript has grown exponentially, the programming language’s ability to express the relationships between different units of code and mitigate coding errors early on hasn’t kept pace. Along with JavaScript’s inconsistent semantics, this makes JavaScript-driven app development difficult to manage at scale.

    Released in 2012, TypeScript was created to address JavaScript’s deficiencies in developing large-scale apps. It’s an open source, strongly typed programming language that builds on JavaScript by adding optional static typing. Types enable structuring and validating code before it’s executed, which is beneficial when developing large apps. They also provide additional information about code, which serves as better documentation for other developers and facilitates collaboration.

    TypeScript is a superset of JavaScript, which means any JS code is also valid TS code—provided the TS configuration is set to be compatible with it. It outputs code in pure JavaScript and allows developers to liberally use JS libraries, tools and frameworks. It runs on Node.js or any browser that supports ECMAScript 3 or higher. It also supports object-oriented programming features. 

    JavaScript Drawbacks

    JavaScript is one of the world’s most popular programming languages and works extremely well for small projects. However, its disadvantages—many of which affect project costs and code delivery time—make a strong case for considering alternatives such as TypeScript, particularly for larger projects.

    Most of these drawbacks have to do with the lack of types and compile-time error checks, making JavaScript less than desirable for server-side code in enterprises and large codebases. The following are just a few of its disadvantages:

    • JavaScript employs dynamic typing, which means scripts can compile even if they contain errors that can prevent them from properly running.
    • Because JavaScript is dynamically typed, it allows one variable to have multiple properties assigned to it. It doesn’t instantly let developers know what a variable can contain. That makes it easy to assign the wrong properties.
    • Since JavaScript is an interpreted language, errors can only be found during runtime. Code needs to run before being tested and validated, so it can take considerable time to find bugs and errors in JavaScript code.
    • To eliminate inaccuracies, it’s necessary to manually verify types and the syntactic correctness of the code. This lengthens development time and extends the delivery cycle to production, increasing development costs.
    • JavaScript code is executed on the client side so it’s viewable to the user. As a result, bugs and oversights have the potential to be exploited for malicious purposes. 
    • Lengthy onboarding of new developers can result because developers must figure out the properties of the structures they’re working with, as well as the data types. While JSDoc can be used for documenting code and annotating types, there’s still the need to synchronize the actual code and documentation. The lack of synchronization, in turn, can mislead developers and complicate the introduction of new, business-requested features.
    • JavaScript is prototype-based, not class-based. It’s not considered a pure object-oriented programming language, although it can follow some object-oriented programming principles.

    The TypeScript Advantage

    TypeScript is a superset of JavaScript. If a developer knows JavaScript, there’s not much of a learning curve to take advantage of the features TypeScript offers that make up for many of JavaScript’s deficiencies—and it can offer additional benefits.

    For example, with JavaScript, variables can start as one property, and then change into an object or a string. These inconsistencies can generate problems that are difficult to resolve in large apps. TypeScript, on the other hand, analyzes the code and tries to determine proper variable types prior to runtime. Once a variable type is assigned, it stays unchanged. TypeScript’s compiler also helps shorten the QA and testing process in later stages of development.

    TypeScript also helps developers quickly figure out the purpose of a variable within the code. It can also suggest available properties in functions, classes or components. Being able to quickly look up a variable is important because it reduces the likelihood of calling the wrong function or accidentally skipping a variable declaration. Any reduction in bugs and errors reduces the time required for fixing those issues and, therefore, reduces overall development time. That gives developers more time to work on app logic and fix errors that can be detrimental to in-app performance and usability. According to a postmortem analysis by Airbnb, 38% of bugs they encountered were preventable with TypeScript after the company adopted it throughout the organization. 

    As a static language, TypeScript performs type checks upon compilation, flagging type errors and helping developers spot mistakes early on in development. Reducing errors when working with large codebases can save hours of development time.

    Clear and readable code is easy to maintain, even for newly onboarded developers. Because TypeScript calls for assigning types, the code instantly becomes easier to work with and understand. In essence, TypeScript code is self-documenting, allowing distributed teams to work much more efficiently. Teams (and individual developers) don’t have to spend inordinate amounts of time familiarizing themselves with a project.

    TypeScript’s integration with editors also makes it much easier to validate the code thanks to context-aware suggestions. TypeScript can determine what methods and properties can be assigned to specific objects, and these suggestions tend to increase developer productivity.

    TypeScript is widely used to automate the deployment of infrastructure and CI/CD pipelines for backend and web applications. Moreover, the client part (for example, when using Angular) and the backend can be written in the same language—TypeScript. This flexibility allows an engineer who knows one programming language to cover all parts of the system.

    Because TypeScript essentially transpiles to JavaScript, migrating existing code to TypeScript is easy and fast. It can typically be accomplished simply by running the compiler and adding typing where it’s not recognized by the language. There’s no need to make changes to the code.

    The benefits of TypeScript have been noticed by developers. TypeScript was used by 78% of the 2020 State of JS respondents, with 93% saying they would use it again. TypeScript continues to grow in popularity. It was voted the second most-loved programming language in the Stack Overflow 2020 Developer survey. 

    TypeScript & AWS: Better Together 

    There’s another compelling reason to consider TypeScript for large-scale app development projects. It’s fully supported by AWS, the leading cloud platform for modern app design and development as noted in Gartner’s Magic Quadrant for Cloud Infrastructure and Platform Services.

    The following services and tools have seamless integration out-of-the-box with TypeScript, enabling you to use this language for a vast number of tasks:

    • AWS CDK provides infrastructure-as-code (IaC) to automatically deploy the entire infrastructure in one click. You can also automate the creation of CI/CD pipelines for the future launch of specific jobs on demand.
    • AWS Lambda allows you to run computation tasks in serverless mode using automatic scaling and an efficient pricing scheme.
    • Amazon EC2, ECS and EKS can cover any of your tasks and provide a wide range of solutions for running apps written in TypeScript—from bare metal servers to complex clusters of hundreds of Docker containers.

    Optimize Your Application Development Projects

    All decisions made during an application development project can impact overall costs and time to market. That includes going with the right programming language and using the most appropriate cloud platform and resources. 

    When approaching an app dev project, a one-size-fits-all approach rarely works. Take the time to define your needs and priorities and select the best resources to deliver the best results.

  • Digital Transformation Driving VSM Adoption

    Digital Transformation Driving VSM Adoption

    The number of organizations using value stream management (VSM) to bridge the divide between DevOps and the rest of the business is expected to dramatically increase over the next two years. The shift is due, in part, to investments in digital business transformation initiatives.

    A survey of more than 500 executives, IT and business leaders conducted by Dimensional Research on behalf of Broadcom, a VSM platform provider, finds the percentage of organizations employing VSM will rise from 42% today to 70% in the next two years. Nearly three-quarters of organizations (72%) that are not currently using VSM plan to do so in the next 18 months or more.

    The survey also finds that 85% of organizations are collecting some subset of value stream metrics today as part of an effort to deliver solutions faster (56%), improve decision making (55%) and increase transparency (54%).

    Laureen Knudsen, chief transformation officer at Broadcom, said that as organizations embrace DevOps best practices more broadly to drive digital business transformation initiatives, they need more visibility into the application development process. VSM surfaces the insights required to not only identify bottlenecks but also track how changes in application delivery timetables will impact key performance indicators (KPIs).

    VSM traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to an automated process using DevOps best practices—and as organizations realize just how dependent they are on software—an appreciation for the value of monitoring the impact of missed software development deadlines on the business is growing steadily. VSM platforms automatically collect technical metrics from DevOps tools that are then correlated against the KPIs the organization decides to track.

    The Broadcom survey found more than 96% of respondents’ companies are already in the process of adopting digital transformation. Strategic objectives include increasing efficiencies (70%), improving product quality (67%) and improving customer value (63%).

    Most respondents (92%), however, are anticipating product development challenges for 2022. The biggest product development challenge cited is a lack of visibility throughout the product life cycle (45%) followed by inefficient processes (44%), lack of resources (42%) and enterprise-wide lack of understanding of how products deliver customer value (42%). A full 89% of the business leaders surveyed also noted they continue to struggle with organizational silos between strategic development and operations; 93% noted that better alignment between teams would improve their organization’s overall return on investment (ROI) in software development. A total of 95% said they believed VSM would optimize their product life cycle processes.

    Knudsen said that, in time, artificial intelligence (AI) technologies will increasingly be infused into VSM platforms to enable automated feedback loops between the business and DevOps teams. In the meantime, DevOps teams should be prepared to adjust project priorities based on the needs of the business and to endure a higher level of scrutiny as business stakeholders become more involved in setting the software development agenda.

  • How to Build Healthy Engineering Teams

    How to Build Healthy Engineering Teams

    A common challenge today for engineering teams is the increasing complexity of their jobs and figuring out how to make it both productive and enjoyable without burning out.

    Over the last 10 years, the role of a software engineer has evolved drastically. Software continues to reach unprecedented scale, it is becoming more complex and customer expectations are higher than ever. Organizations from all industries are now becoming software companies and, with the pandemic, everyone is feeling the effects of burnout.

    There are close to a million unfilled IT jobs in the United States. To ensure organizations are able to continue innovating, the industry needs the tools, state of mind and reliable practices to make this career sustainable.

    Creating an industry with healthy productivity is paramount. But too much of a focus on going faster without addressing burnout is a recipe for disaster. Engineering managers need to constantly balance both. Here are some things they should keep in mind:

    Invest in Engineering Productivity

    Companies are increasingly hiring for roles focused on engineering productivity—there are currently hundreds of open job postings from organizations looking for these skills. These jobs are aimed at making developers and engineers’ lives and work easier by focusing on streamlining how things are done within the engineering organization—including improving developer workflow processes, execution efficiency and product quality. They are often responsible for building internal tools that support cross-functional and developer workflows. Even with a relatively small engineering team, organizations can start thinking about bringing on a team member dedicated to making engineers’ roles within the company easier.

    Focusing on Healthy Productivity

    Productivity is, and will always be, extremely important, but potential burnout should also be seriously considered in the process. Remote work during the quarantine and the pandemic has brought this front and center. When people don’t have enough deep work time, they often work longer hours which can eventually lead to burnout. An average employee has 11 minutes to focus between distractions at work and then, after an interruption, it can take around 23 minutes to return to the original task. In addition, the average worker attends 15 meetings per week.

    There are many questions about how workers’ productivity has been impacted since early 2020, and research has found that developer productivity isn’t a problem—but burnout is. From March to December 2020 the study found:

    • Deep work time—a two-hour period of uninterrupted work—decreased by 22% between March and December 2020.
    • Average time in meetings went up by 67% from March to December 2020.
    • Pre-pandemic, 10% of developers were showing “always-on” behaviors at work, but that percentage went up to 15% and then to 20% by the end of the year.

    Focusing on driving healthy productivity—where developers are productive but not overworked—is key to keeping your employees.

    Strengthening Engineering Managers

    Managers play a key role in keeping engineering burnout in check. Ensuring that managers ‘manage well’ is not a new idea, but today there are particular complexities that make the engineering manager role both uniquely challenging and especially important.

    It is now widely acknowledged that culture is a considerable part of what gets employees to stick around. But culture isn’t only employee benefits like trendy offices, great snacks and other relatively superficial—though still important—benefits. What really matters is identifying and building teams that really care about one another on a personal level and making sure that incoming employees feel the same.

    With engineering teams, there is a tendency to focus primarily on the technology being created rather than the people who are creating it. While this approach can absolutely result in successful products, it is often the default management style for managers who don’t have the tools to do otherwise. Moving from software engineer to manager requires a whole new skill set that involves different communication styles, time management, organization, tools and software, scoping work, learning how to effectively delegate and identifying the right people to complete the team.

    As challenges continue to evolve, organizations need to ensure that engineering managers are able to support each individual on their team. It is so important to make sure that people feel aligned with a mission they care about and that their career interests and goals are being met. Not all of those can be measured with data, so managers have an all-important role in keeping up with the pulse of the team.

    Building Helpful Tools and Growing Developer Communities

    In the last decade, the speed of innovation in enterprise technology has skyrocketed and the amount of code and tools developers need to master has increased. At the same time, the number of unfilled job openings continues to grow. There are a lot of great trends that are helping to close this gap including low-code and no-code tools as well as a massive increase in community resources.

    No-code/low-code tools: As both technical and non-technical organizations hire an increasing number of developers, low-code and no-code have become more prevalent. With frameworks that allow even those without a technical background to deploy software, no-code tools open development capabilities to an increasingly diverse subset of people. While these tools will not replace developers, they will make it possible for more people to enter the field of software development and help companies continue to innovate.

    Developer community: The amount of resources available to new and existing developers has also skyrocketed in the last several years from open source communities to Stack Overflow to the ability to simply Google how to do something in code. The Linux Foundation’s extensive training catalog is one example; even Medium has a wealth of basic technical info, how-tos and deep dives available. If you’re looking to adopt a new tool, one of your main priorities should be to look at the size of the community so that you can easily troubleshoot problems if they arise. Having access to resources from community members that have gone through the exact same problems you encounter is priceless.

    The above are all just a start. Teams can go even further by finding and adopting analytics tools to dive deeper into specific productivity metrics. These can give managers and executive teams the hard data they need to make educated decisions that will help them keep their teams and drive innovation. It is worth investing the time and the tools to maintain your engineering resources. By doing these things, organizations can reach and maintain healthy productivity.