devopsy.kinsta.cloud

Category: DevOps 101

  • Balance Software Quality, Dev Speed and Cost With CI/CD

    Balance Software Quality, Dev Speed and Cost With CI/CD

    In many cases, success in the business world relies on software, be it a compelling mobile app, desktop application suite, interactive website or even an embedded system for the IoT. Because of this need, companies with mature software development processes enjoy a significant competitive advantage over those without. Part of fostering this maturity involves crafting quality software with high velocity but low costs.

    Modern software development methodologies, like Agile and its variants, play a key role in crafting applications in an effective fashion. As more companies adopted an Agile approach, the movement also fostered DevOps, a management structure combining software engineering and network administration teams while leveraging automation to build apps more quickly. In many cases, the ultimate goal for these adopters involved achieving the programming Holy Grail of continuous integration and continuous delivery (CI/CD).

    So, let’s take a closer look at continuous integration and delivery and how it helps companies successfully balance quality, speed, and cost in their software development projects. In a competitive global economy, adopting this approach remains a crucial differentiator, whether or not a business also fully adopts DevOps. In either case, understanding the benefits of CI/CD helps your software company achieve its business dreams.

    A Closer Look at DevOps

    As noted earlier, DevOps somewhat grew out of the Agile movement, but it isn’t a software development methodology in and of itself. Instead, it involves a company merging its software development team and its network administration staff largely responsible for helping the process of building applications. It increasingly leverages modern technologies like containers and virtualization for development, QA and production servers and automation for builds and testing processes.

    This organizational structure and mixture of tools combine to help companies build high-quality software with high velocity and at a lower cost. A mature community grew around DevOps, including tools, best practices, process experts and more. While DevOps originally served as the sole domain of large enterprises, now businesses of all sizes involved in software development benefit from adopting this approach.

    Defining Continuous Integration and Continuous Delivery (CI/CD)

    Continuous integration effectively automates the critical software development processes of builds and testing. It especially makes sense for shops using multiple programmers, as it works with the team’s source code version control system to ensure all programming changes are merged and remain in sync whenever a developer checks in their code.

    Any check-in typically kicks off a process where unit tests and a build are automatically run to ensure those changes don’t “break the build.” In pre-DevOps days, this tended to be a highly manual effort, leading to inefficiencies in any software development project. In short, the team only discovered any integration issues after a manual test. Automation now plays a crucial role in making this aspect of application building significantly more efficient. CI remains a critical best practice in any DevOps shop.

    Continuous delivery shares many similarities with continuous integration, especially its use of automation and the latest software development tools. However, instead of performing builds for internal developers and the QA team, CD focuses more on delivering a software product for release to a user community, customer or the public at large. Again, this is another part of the software development process that led to inefficiencies in the days before DevOps and automation.

    In terms of software development for mobile apps, CD ends up being the last part of the development process before the app gets delivered to the App Store or Google Play. It also comes into play with any fixes or feature improvements after the app is on the market. A key aspect of engendering goodwill among your customers directly relates to the speed of app improvements. Adopting a CI/CD approach plays an important role in making app changes with high velocity.

    CI/CD is the Heart of Successful Modern Software Development

    Simply stated, if your company wants to be a successful software developer, adopting both continuous integration and continuous delivery remains crucial. Following an older, manual approach causes too many bottlenecks and inefficiencies to thrive in a highly competitive industry. No matter how great your startup’s idea or app design is, failure to deliver it with high velocity ultimately results in failure. Once again, this same concept applies to fixes and feature enhancements after the app’s launch.

    At the same time, you don’t need to fully embrace the DevOps organizational structure by creating a separate team made up of software engineers and network administrators. At many startups with a small headcount, your developers might handle many of those network tasks, including managing virtual servers and containers. Hiring a network admin or two might be an unneeded luxury.

    In the end, if you want to build your startup’s app in the most efficient manner, adopting the CI/CD approach makes perfect sense. It provides speed that allows your team to effectively balance quality, speed and cost, resulting in a great app without overspending. It’s the right approach for any successful software project.

  • Back to Basics

    Back to Basics

    We here at devopsy.kinsta.cloud do sometimes suffer from The Curse of Knowledge. We write about DevOps regularly for an audience that is doing or managing DevOps. We assume knowledge, but there are still a fair number of people and organizations who are unclear about some of the terminology/technology that we talk about.

    So if you are a regular reader of my blog, this might be a redundant post—but read on because it might have info you haven’t had a reason to consider yet.

    I’m going to start with the obvious—how most readers got here to begin with: DevOps. DevOps is automating the build process so that builds are automated and repeatable. Teamed with Agile development, DevOps means that development teams can rapidly iterate through development and generate regular updates to their applications. Everything else in this blog is based on the premise that it is running in a DevOps environment.

    Continuous integration: Typified by Jenkins, continuous integration (CI) is the part of DevOps that runs the automated builds. It includes reporting and defect resolution only in the sense that it feeds into other systems that track defects. With CI in place, a developer or DevOps engineer can say, “Okay, ready to test a build,” and with one command, can kick off a build that will result in a finished artifact. Or result in a built product, anyway. ‘Finished’ is optional, and the target of CI is not generally a running application.

    Continuous delivery: One of the most confusing things for new DevOps people is CD. The way that the space evolved, there are actually two things that CD could stand for; continuous delivery–automated build of the complete application —or continuous deployment—delivery of a running application onto infrastructure. Continuous delivery is straightforward and means all the bits of the application are code complete–or at least the current state of the application is complete enough to build an application. Continuous deployment is much more convoluted. It might mean deployed to a development environment for developer-level testing or a test environment for running automated (continuous testing) tests on or in production. It might be a staged rollout, where users are siphoned over, or it might be a hard rollout where the old version is replaced by the new in a manner similar to ripping a Band-Aid off.

    Continuous test: Automated testing is at the heart of continuous test (CT), and it is only now becoming a real possibility for most short-staffed enterprises. Advancements in machine learning (ML) mean that tests can be run, results filtered to eliminate false or duplicate results, and IT staff is only notified of the important bits. Unlike traditional testing, staff is required only to create the tests and to look at meaningful results.

    Infrastructure-as-Code: Infrastructure-as-Code (IaC) is the ability to define all relevant elements of infrastructure with text files. Often this is done in YAML and sometimes in a variety of other formats. The idea is that infrastructure provisioning can be on-demand and adaptable. It is certainly more agile to change a text file from port 80 to 8080 and then run a command to process the text file–now the port is documented and whenever needed the command can be re-run to move to a known state. IaC largely relies upon software implementations over physical. While the idea of software-defined networking (SDN) has fallen out of favor, the underlying principles are everywhere and part of IaC, for example.

    GitOps: All the rage these days, GitOps is probably best defined as applying DevOps to operations. That does sound weird, but I like to break it up as “traditional DevOps is DevOps, while IaC (to a lesser extent) and GitOps (to a huge extent) are DevOps.” The point being that GitOps uses the text files generated in IaC and worker nodes generally designed for continuous deployment and then performs operations tasks based on those text files. If IaC defines the entire environment that an application needs and DevOps defines all of the sources that an application is composed of, bundling the two together will enable full-on automation from conception to decommissioning. When a new version of a source file or configuration file is checked into Git, the system then makes certain that every instance of the application is updated with the new version. Of course, this process, like every one listed here, is far more complex than that in implementation; we are talking about ‘what, not how’ at this level.

    All of this really is the very tip of the iceberg, but that was the goal here – to offer readers a place to start if they’re finding themselves looking at DevOps for the first time. As you dig deeper, things like DevSecOps and test driven development (TDD), or defect tracking and Agile methodologies start to play into the landscape, and maybe I’ll write an intro bit for those also. But this time, we’re out of space.

    As always, keep rocking it. No matter which or how much of the above you are using, if the organization’s applications are up and running, that’s you. And you deserve more kudos than you are likely getting. But keep grinding through—the rest of us get it, and thank you.

    Image source: Photo by Towfiqu barbhuiya on Unsplash

  • DevOps Done Right: How to Succeed in DevOps From Day One

    DevOps Done Right: How to Succeed in DevOps From Day One

    Whether you are diving into DevOps for the first time or trying to do it right this time, DevOps Onramp provides all the information you need for a successful DevOps journey. Join us on May 4, 2023, to learn how to get started with DevOps—and how to do it right.

    You’ll learn:

    • DevOps best practices, processes and the tools you’ll need
    • Tips and tricks from experienced practitioners sharing their real-world experiences
    • The basics of DevOps
    • How to choose the right technologies
    • Common challenges and how to overcome them
    • The benefits of DevOps as a methodology and a career
    • And more!

    As organizations face increasing pressure to adapt faster and become more agile, getting DevOps right and adopting a DevOps mindset is crucial to deliver high-quality software faster and increase business value. And that opens up great opportunities for anyone looking to start a new career or pivot from an existing role in technology.

    DevOps has become the standard of software development methodologies and it’s critical for successful digital transformation. Adopting DevOps—and doing it the right way—can benefit not only your organization but also your customers and end users by fostering innovation, reducing time to market, increasing development productivity, improving product quality and reliability and reducing costs.

    That’s why many big companies, such as Amazon, Netflix, Facebook and many others have adopted a DevOps mindset—and DevOps practices. And as more businesses are looking to move to the cloud and transition into DevOps, there are plenty of job opportunities available for DevOps engineers at various levels.

    DevOps is a growing field with a lot of opportunities for professional growth. According to a research study by Global Market Insights Inc., the DevOps market is expected to surpass $30 billion by 2028. Due to the high demand for skilled DevOps engineers and the shortage of qualified DevOps professionals in the industry, there is no better time to upskill than now.

    Whether you are diving into DevOps for the first time or trying to do it right this time, DevOps Onramp provides all the information you need for a successful DevOps journey.

    At DevOps Onramp Virtual Summit, taking place on May 4, 2023, you’ll get all the knowledge you need to get started with DevOps —and how to do it right. Join us to learn about DevOps best practices, processes and tools and get tips and tricks from experienced practitioners sharing their real-world experiences. We’ll go through the basics of DevOps, how to choose the right technologies, common challenges and the benefits of DevOps.

    One thing is for sure: The future of DevOps is very promising. The rush has started—don’t be left behind!

    DevOps Onramp Virtual Summit - Submit your talk

    If you’re interested in becoming a sponsor, please contact us. For more information, please visit the DevOps Onramp website.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers. Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    LinkedIn

    Apple
    San Diego, California
    Site Reliability Engineer (SRE) – Video
    $115,000 to $217,500

    SimplyHired

    ScientiaMobile
    Reston, Virginia
    Senior DevOps Engineer
    $110,000 to $150,000

    Monster.com

    Larsen & Toubro Infotech Ltd.
    Farmington, Connecticut
    DevOps Engineer
    $110,000 to $130,000

    Indeed.com

    TherapyNotes.com
    Remote
    Senior DevOps Engineer
    $105,000 to $155,000

    Dice.com

    MRoads
    Dallas, Texas
    Platform Engineer – SRE
    $100,000 to $120,000

  • The Ultimate Guide to Hiring a DevOps Engineer

    The Ultimate Guide to Hiring a DevOps Engineer

    The economic downturn, pandemic management challenges, supply constraints and the ongoing Russian-Ukraine war have led to layoffs in many industries. While these events also impact the technology industry, it does not necessarily have to mean disaster for DevOps professionals who find themselves looking for a new role.

    Tech recruiters are looking for candidates with the right skills and experience to establish or enhance their digital presence to reach customers and clients without compromising security.

    In this article, we will explore the role of a DevOps engineer in more detail, including the skills and knowledge necessary to succeed in this field. We will also discuss how to hire a good DevOps engineer and the skills you should focus on while hiring someone for this role.

    Understanding the DevOps Engineer Role

    Continuous Integration and Continuous Delivery (CI/CD)

    DevOps engineers are responsible for creating, designing and maintaining a CI/CD pipeline using tools such as Jenkins, Gitlab, CircleCI or AWS Code Pipeline. One of their main goals is to streamline the deployment process and reduce the time it takes to deploy software, potentially cutting deployment time from a lengthy process to a quick one.

    Automation of Repetitive Tasks

    DevOps engineers apply their Bash and Python scripting skills to automate various tasks like configuring infrastructure, servers, containers and cron jobs.

    Security

    As part of their responsibilities, DevOps engineers are charged with implementing security best practices and ensuring code, applications and systems are secure. This involves responding to attacks, performing security audits, hardening servers and implementing user security controls like managing AWS accounts, SSH keys, Linux/Unix privileges and permissions, SSL certificates and encrypting data like API keys using tools like Amazon KMS.

    Application Troubleshooting

    DevOps professionals are also responsible for troubleshooting issues that arise in the software development process, deployed applications and web applications and identifying opportunities for improvement.

    Administering and maintaining databases

    Some DevOps professionals are also responsible for an organization’s data; building and troubleshooting database clusters to meet business needs, managing streaming data and more. DevOps teams ensure that systems are configured correctly and are scalable to handle increasing workloads and support business growth.

    Here are some soft skills that can be beneficial for a DevOps engineer to have:

    • Excellent communication skills: DevOps engineers often work closely with developers, IT staff and management across an entire organization, so they should communicate technical concepts and ideas effectively.
    • Collaboration: DevOps is all about teamwork and working closely with other team members, so working well with others is crucial.
    • Problem-solving: DevOps engineers need to be able to troubleshoot problems and find creative solutions to challenges that may arise.
    • Adaptability: The field of technology is constantly evolving, so DevOps engineers must adapt to new tools, technologies and processes.
    • Time management: DevOps work can be fast-paced and involve multiple projects, so managing time effectively is important.
    • Continuous learning: To keep up with the rapid pace of change in the tech industry, DevOps engineers need to be committed to constant learning and staying up-to-date with new developments in their field.

    Hiring Process

    The hiring process for a DevOps role can vary depending on the specific needs and goals of the organization as well as the availability and skill level of candidates.

    However, some general steps are common to many DevOps hiring processes:

    1. Define the role and responsibilities: Identify the skills and experience required for the DevOps role and the specific tasks and projects for which the individual will be responsible.

    2. Source candidates: Use various methods to find potential candidates, including job boards, current employee referrals and professional networking sites.

    3. Review resumes and cover letters: Look for candidates with the relevant technical skills and experience and the ability to communicate effectively and work well in a team.

    4. Conduct initial phone screens: Use this opportunity to learn more about the candidate’s background, skills and interests and to assess their fit for the role.

    5. Administer technical assessments: Depending on the specific needs of the role, you may want to give candidates a technical assessment to evaluate their knowledge and skills. This could include a coding challenge, a written test or a hands-on technical project.

    6. Schedule in-person interviews: Use this opportunity to learn more about the candidate’s personality, communication skills and work style. You may also want them to meet with other team members to understand how well they would fit in with the company culture.

    7. Check references: Contact the candidate’s past employers and colleagues to get a sense of their work history and performance.

    8. Make an offer: If the candidate is a good fit for the role and the company, extend a job offer and negotiate terms.

    9. Onboard the new hire: Once the candidate has accepted the offer, provide them with the necessary training and resources to get up to speed in their new role.

    By following these steps, you can effectively hire a DevOps engineer who will contribute to the success of your organization.

    Onboarding and Training

    Onboarding and training are essential components of the employee experience and can significantly impact the success and retention of new hires.

    This is especially true for DevOps roles which often require a broad range of technical skills and knowledge and the ability to work effectively with other teams and departments.

    Here are a few reasons why comprehensive onboarding and training are crucial for DevOps roles:

    1. Because DevOps roles often involve working with complex technical systems and processes, a comprehensive onboarding and training process is crucial to help new hires quickly learn the tools, technologies and techniques they need to use in their role, enabling them to begin making contributions sooner.

    2. In DevOps roles, it is common to work closely with other teams and departments. An onboarding process that helps new hires understand the company’s culture and values as well as the roles and responsibilities of other team members can facilitate the building of strong working relationships and effective collaboration.

    3. In DevOps roles, the ability to adapt to rapidly changing environments is often necessary. An onboarding and training process that helps new hires understand the company’s goals and objectives and its direction can enable them to see how their role fits into the larger context and how they can contribute to the organization’s success.

    4. Onboarding and training can help new hires feel welcome and supported in their new role. In addition, a positive onboarding experience can help new hires feel more engaged and motivated, leading to better retention and performance.

    By investing in an effective onboarding and training process, organizations can set new hires up for success and ensure they can contribute to the company’s success from the start.

    The Bottom Line

    Hiring a DevOps engineer is a critical decision for any organization looking to optimize its development and operations processes. A skilled DevOps engineer can help your organization improve efficiency, speed up application deployments and reduce downtime. To hire the best DevOps engineer for your company, it is essential to define the role and responsibilities, source a diverse pool of candidates and assess their technical skills, communication abilities and fit with your company culture.

  • Developer’s Guide to Fuzz Testing

    Developer’s Guide to Fuzz Testing

    Fuzz testing continues to grow in popularity among developers within the open source community. Google’s open source security (OSS) team recently reported finding more than 40,000 bugs in 650 open source projects through the use of fuzz testing. But if you have no clue what fuzz testing is (yet), don’t worry. You’ve come to the right place.

    What is Fuzz Testing?

    Fuzz testing is a dynamic testing method for finding bugs and security issues in software. During a fuzz test, a program or a function under test gets executed with invalid, unexpected or random inputs to uncover unlikely or unexpected edge cases. 

    Value of Fuzzing for DevSecOps 

    As we know, DevSecOps extends the approaches of DevOps and Agile by adding suitable security testing methods alongside every phase of the software development life cycle (SDLC), creating a dynamic and continuous testing process. 

    Part of that testing process can and should involve fuzzing to detect security and stability issues at all phases of the SDLC and empower developers to ship software quickly and securely. For example, to prevent regressions from going live by running automated fuzz tests on every code change.

    Especially in the automotive industry and complex embedded projects, where a lot of untrusted and complicated data gets processed, fuzzing brings excellent benefits to DevSecOps. Indeed, developers can apply fuzzing similar to unit testing to automatically test their security-critical modules for potential vulnerabilities. But with fuzzing on an integration level, they can also cover all the complicated and dangerous edge cases that can occur in the interaction between different modules. 

    Fuzz Testing Benefits

    Fuzzing code generates thousands of automated test cases in a second, with the fuzzer receiving in-depth feedback on code coverage and the program states reached to simulate the interaction of different modules during the execution of the source code. The fuzzer can adapt and mute its inputs based on runtime feedback in the following iterations to maximize code coverage. Some of the benefits are:

    1. (Almost) no false positives: If you find a crash, fuzzing provides you with the error source and the malicious input that caused the issue. So, you can be sure that each finding is a real vulnerability.
    2. Debug reproducible findings: Modern fuzz testing tools will provide you with the input causing the issue, including the source of the error. With this, you already have a lot of helpful information to reproduce the bug and load it directly into the debugger. 
    3. Find issues in forgotten edge cases: Because fuzzing is executing a program with invalid or random input, it also uncovers unlikely and unexpected edge case errors that would not otherwise have been revealed.

    Who Uses Fuzz Testing?

    As cybersecurity regulations and standards continue to expand globally, more and more organizations are extending cybersecurity programs and running automated security testing before they ship software. Whole industries, especially those that involve advanced quality and security regulations, are setting standards for security testing that recommend fuzz testing, including automotive, aviation, finance, healthcare, telco and energy.

    Digging deeper into the automotive industry, for example, a variety of International Organization for Standardization (ISO) and other organizational standards now recommend fuzzing:

    Best Practices

    The most effective way to do security testing, fuzzing included, is to do so continuously. This means integrating fuzzing right into your CI/CD pipeline. Doing so creates quick feedback cycles so developers can fix security vulnerabilities before the code is shipped. Integrating fuzzing tools into code hosting systems like GitHub is also valuable. Doing so allows communication and alerts to be shared across your DevOps team as soon as a problem is uncovered, which helps to facilitate fixing vulnerabilities. 

    What Bugs Can I Find?

    While the practice remains relatively new, fuzzing has already discovered thousands of bugs across different use cases. Bug and vulnerability types discovered include:

    • Remote code executions
    • Injections, which can be triggered by untrusted inputs 
    • Memory leaks: Incorrect memory allocation 
    • Exposure of sensitive data: Accidental exposure of personal data
    • Functional bugs: Inputs that are not being responded to 

    and many more bugs, such as undefined behavior, uncaught exceptions and buffer overflow. Learn more.

    Getting Started

    You can try out an open source fuzzer, like Jazzer (for Java testing) or the CI Fuzz CLI (for C/C++ testing). When you’re comfortable with fuzzing and want to use this approach in more complex environments, enterprise solutions offer added features like API fuzzing, reporting and CI/CD integration. 

    So give it a shot and join the community of open source developers using fuzzing to quickly and securely ship their software. 

  • CNCF Survey Predicts Growing Wasm Momentum

    CNCF Survey Predicts Growing Wasm Momentum

    A survey of 93 developers conducted by the Cloud Native Computing Foundation (CNCF) found more than a quarter (28%) are using WebAssembly (Wasm) in their cloud-native development projects, with another 36% planning to do so during the next six to 12 months.

    The survey, published this week, is effectively a straw poll that found 42% of respondents are developing or plan to develop server-side applications using Wasm, while 48% are combining or planning to combine server-side workloads with client-side applications.

    Originally developed five years ago by the World Wide Web Consortium (W3C) to create a common format for browsers executing JavaScript code, Wasm is now starting to be used to rapidly build lighter-weight applications that can be deployed on any server platform. The promise of being able to write an application once and deploy it anywhere is finally being realized some 25 years after the initial introduction of the Java programming language.

    The survey found 70% of respondents viewed Wasm runtimes as a disruptive emerging technology. The primary programming languages used in association with Wasm are Rust (59%), Go (47%) and JavaScript (46%), the survey found.

    Nearly two-thirds (63%) said they are both porting new applications using Wasm and migrating existing workloads, compared to 37% who said they were creating new applications only. The primary reason cited for migrating workloads to Wasm was application portability (78%), better security (77%) and improved runtime performance (70%).

    Security ranks high because existing approaches to building applications rely on the aggregation of software components that tend to lack distinct boundaries between them. As a result, it becomes relatively simple for malware to infect all the components of an application. Wasm code runs in a sandboxed environment that isolates execution environments in a way that eliminates the ability of malware to laterally move across an application environment.

    Target platforms for Wasm applications include serverless computing frameworks (63%), edge platforms (54%) and the web (52%), the survey found.

    The biggest barriers to adoption were tools (46%) and lack of standards (45%). Just over half (56%) of respondents said Wasm developer tools are missing features and are difficult to use. A full 81% said they would like to see vendors provide full-featured and stable Wasm tools and projects.

    Matt Butcher, CEO of Fermyon, a provider of a platform for building Wasm applications, said that while survey respondents most likely represented more advanced developers, it’s clear Wasm momentum is starting to build. Much like JavaScript before it, Wasm is about to jump from the client to server-side application environments, he noted.

    Less clear is whether Wasm represents the next era of cloud-native computing or is simply another type of software artifact that will be employed to build applications alongside other artifacts such as containers.

    Wasm isn’t necessarily going to replace existing approaches for building applications any time soon, but it does provide an alternative to serverless computing frameworks for developing lighter-weight applications that run faster. Existing serverless computing frameworks typically use containers that are much slower to start up than Wasm code running natively on a platform, which accounts for why developers are looking to embrace the format to improve overall application performance.

    One way or another, more Wasm code will soon be finding its way into DevOps pipelines. The issue is determining how to incorporate it alongside all the other code moving through those pipelines.

  • DevOps Principles, Implementations and Culture

    DevOps Principles, Implementations and Culture

    When organizations begin using DevOps for application development, many only reference DevOps as part of their infrastructure and select a subset of DevOps before understanding the cultural and process changes needed for success. Instead, organizations must first determine which ‘Ops’ approach best promotes a DevOps mindset and integrate their workflows into their culture. In doing so, these organizations will better align their development and operations teams on common goals and protocols.

    There are many variations and subgenres of DevOps. However, it’s important organizations understand the ‘Ops’ choices available and choose the one that’s right for them.

    Principles Vs. Implementation Differences

    General DevOps and its subgenres can be split into two groups. The first and “purest” are the principles that these terms focus on unifying two or more industries with operations.

    The second type is those that focus on an implementation type.

    Principle Types

    DevOps: Improving Technical Processes and Culture

    DevOps is the overarching umbrella term for operations that combine Agile development concepts with IT operations and fast-tracks the development and deployment of applications in cloud environments. While there are different subgenres of DevOps, each subgenre is a different application of DevOps methodology, all geared toward making development more agile, stable and efficient. Because DevOps shortens the development life cycle by a significant margin, this streamlined approach to application development is quite popular.

    DevSecOps: Adding Security Checks

    DevSecOps bakes additional security measures into the workflow. Where DevOps typically has security checks at the end of a cycle, IT pros that leverage DevSecOps integrate security early and often in their DevOps journeys. With DevSecOps, collaboration between developers, security specialists and ops is crucial to maintaining agility and delivery speed, but the extra layers of security can slow processes down. DevSecOps leverages fast testing and robust pipelines to favor better code integrity. This method can be beneficial if an organization needs to elevate security during development.

    NoOps: Reducing In-House Teams for Operations

    NoOps is the lofty vision that DevOps is so automated it doesn’t require in-house expertise, meaning no manual intervention is required in processes. NoOps differs from DevOps because there is less focus on Agile and process management. This process assumes that developers do not need to know how to use the automated tools and uses continuous integration techniques to allow developers to focus only on application development.

    Though NoOps speeds up the deployment processes, if used by itself, NoOps lacks open communication and team management. Successful implementation of NoOps is only achievable if an organization does not have lofty technical goals or if its development team is small but strong and able to handle development and operations.

    GitOps: Using Git to Automate

    GitOps has been gaining traction in the development industry over the past two years because of its use of Git to automate continuous delivery pipelines. GitOps is a robust and manageable form of operations because it uses Git as the single source of truth for operations. In addition, due to developers’ familiarity with Git and pull requests, there is no complicated tool to learn, and changes to existing workflows are often unnecessary.

    The GitOps method can also boast that it is backed by some of the market’s most innovative cloud services, thus automating the process of building an update, testing for errors, reviewing code and pushing the update to production. Because Git is the only source of truth with GitOps, it is vital to effectively fortify the Git repository to avoid needless commits or pull requests.

    CloudOps: Implementing Cloud-Native Features

    CloudOps attempts to take more advantage of cloud-native features offered by modern service providers. Since CloudOps focuses on distributed development and deployment, there is no single point of failure, making the whole cloud environment more reliable. In addition, certain parts of the workflow in this type of operation can go stateless, making it cost-efficient as organizations only pay for the resources they actually use. Though CloudOps can be time and cost-efficient, organizations must get the configuration right for the approach to be beneficial, which could mean added complications to configuring CI/CD pipelines.

    CIOps: Requiring CI Operators for Configuration

    Continuous integration Ops (CIOps) is the latest iteration of DevOps, requiring CI operators to configure the infrastructure needed to support new code before deployment. The manual inputs necessary to ensure CI jobs’ correct configuration and deployment location bring advantages and disadvantages. Control over infrastructure allows two deployments to have different infrastructure configurations. The major disadvantages are the required manual intervention leaves room for error and the need to link an organization’s CI tool to its API can pose security risks.

    CIOps is better-suited for smaller development environments where automation is an inconvenience. While CIOps gives developers flexibility in configuring cloud infrastructures, the approach takes time and effort to run smoothly.

    ITOps: Automating IT Management Pipelines

    IT is loosely defined as the management of end user or employee systems. They are the systems that are required to run a core business. The fundamental difference is that there is little to no development. If your business doesn’t require a software engineering team and can function solely on prebuilt applications, then ITOps is for you.

    ITOps is in charge of delivering and maintaining services, applications and the underlying technologies necessary to run a business, covering jobs like system administrator and network administrator. ITOps focuses on updating laptops and office networks in addition to highly-tested commercial software and solutions for constructing the infrastructure, making updating infrastructure components more complicated. When using ITOps, an organization’s CIO will focus on managing the system via automation. 

    Choosing the Best Op for an Organization

    Choosing between the variations of DevOps is a matter of finding an approach that works best for the kind of apps the organization is developing and the cloud infrastructure they use. Though all of the above Ops strategies are based on unique ideas, they tend to focus on the technical side. Contrarily, DevOps stands out for its ability to comprehensively improve workflows and streamline technical processes while fostering a culture of innovation and collaboration in an organization.

  • Microservices Explained: Not Your Father’s SOA

    Microservices Explained: Not Your Father’s SOA

    Microservices are frequently referred to as a variant or derivative of service-oriented architecture (SOA), if not essentially the same thing. While there are similarities and both are designed around the concept of services, that’s where the similarities end. Each was created around a different set of principles and intended to address different problems.

    Microservices architecture is built around key concepts that, when applied, not only differentiate it from other architectures but deliver advantages that accelerate software delivery and help to scale large, complex applications. To deliver on the promise of cloud-native, microservices must be loosely coupled so that, ultimately, they are independently deployable. Any microservice can be updated and deployed—just that containerized microservice—without requiring changes to other microservice(s). Loosely coupled microservices mean they are not sharing databases or maintaining state, for example.

    How big should a microservice be? Or, in other words, how much should it do? The answers range from ‘a single thing’ to ‘a small set of related code with high cohesion’. Another factor is that getting too granular can overrun a microservices-based application with large numbers of microservices, increasing complexity and making triage through observability and tracing very challenging.

    Scaling microservices-based apps is another important factor. Autonomous microservices can be replicated and scaled for performance and workload using container orchestration tools such as Kubernetes.

    Microservice communications are achieved through well-thought-out APIs created around the business or operational capabilities the microservice provides to anyone or anything engaging through the API. The API, and data provided through the API, are often referred to as ‘technology-independent.’ It’s probably better stated that microservice APIs are built using approaches like RESTful and GraphQL over networks that are not tied to any one specific operating environment, technology or programming language. JSON, YAML and XML similarly represent data that is transferable across technologies.

    The following diagram of a media application demonstrates the principles of microservices architecture. Microservices for scheduling media, digital rights management, tracking impressions and adding new ad insertions are loosely coupled, autonomous and have well-defined API interfaces. Each microservice can be changed, enhanced and deployed rapidly and independently of other microservices.
    Microservices SOA

    Service-oriented Architecture, or SOA, emerged to solve a very different problem; the overwhelming size and complexity of monolithic applications. Monolithic applications have very large codebases that often don’t do a good job of compartmentalizing functional or business logic. This makes changes to the codebase challenging even to developers who know much of the codebase well.

    Services in SOA were often used to gather a collection of similar business logic together and then share them as a service with other parts of the application, as needed. Technologies like message buses are used to make requests of a service and operate as traffic managers for requests across multiple services and other parts of the application. While reusability was a critical design consideration, SOA services were still quite large, and deploying services at high velocity was not an important design consideration. SOA services often take considerable time to code and test the service including interdependencies across other parts of the application before deploying as part of a larger software release.

    One important note: There are benefits and drawbacks to microservices and SOA architectures; neither is ‘better’ than the other. Which architecture to use when mainly depends on the purpose of the application you are building. For larger, more complex enterprise application environments that require integration with many other applications, you might choose SOA. That’s a better fit than for smaller applications that don’t require middleware elements for managing the requests within the app or between other applications. Microservices, on the other hand, are better-suited for smaller and well-partitioned web-based systems. They are becoming the standard for today’s cloud-native applications, and also are a great fit for developing a mobile or web application because they give developers more control.

  • The Whats and Hows of APIs: A New Developer’s Guide 

    The Whats and Hows of APIs: A New Developer’s Guide 

    For those who are new developers, you may not know a lot about application programming interfaces (APIs). However, it is likely that you’ve used them before as a consumer or an end user, whether purchasing online, using business communication software to reach colleagues or sharing images from a monogram logo maker on social media platforms, for example. It makes knowing about them helpful, regardless of if you plan to make and use one yourself or want to understand how the tools you use work. 

    Although coding and developer tools can be daunting for the outside world, we’ll put APIs into a language that new developers (and even non-developers) can understand. In this guide, we’ll cover what APIs are and the different types that exist. You’ll also learn how they work and how you can use them. By the end, hopefully, you’ll be more comfortable with APIs and know how they impact you and your business.

    What Is an API?

    An application programming interface is a piece of coding used by developers to communicate between different devices, systems, or applications. It allows information to be passed on—allowing procedures to be followed across multiple platforms. Depending on the API, this could be transferring data, images, videos, text, files and other content, or allowing developers to connect through the use of backend-as-a-service (BaaS) to link their apps to the cloud. APIs are often used in a business context and for personal projects or other purposes. 

    Generally, APIs are concerned with the raw information and passing this on to another program rather than the appearance or visual side of these applications. Another set of coding is used instead to build the aesthetic and usability of the interface, while the API tends to be less visible to users. Nonetheless, they form an essential part of our technology stack today, allowing systems to integrate and become more agile, making applications easier for users to navigate.

    Image sourced from developers.facebook.com

    For example, when you refresh your omnichannel communications application, a request is sent to the API to check other linked programs for new messages on your social platforms or calls to your 800 numbers for business. These programs inform the API of new communications and send the appropriate data across. The API returns this data to the application you are using, enabling you to read the messages from here or notify you of no new calls.

    Types of API

    1. Private

    A private API is used internally within a team, created by developers who work for the company or organization. It can help make highly personalized APIs for the needs of your business and adapt the API as and when needed. Private APIs can’t be used or worked on by external developers, as it is purely for your in-house team. These APIs tend to focus on aiding your company’s productivity and project management across multiple applications.

    2. Partner

    Alternatively, partner APIs are used externally with companies that your business collaborates with. Often, this transfers information between businesses, such as within an affiliate scheme or for external postage of online orders. However, APIs can also share and update files such as your release of liability contract or emergency procedure templates. Developers from both companies can improve the API system to effectively share data between partners. 

    3. Open/Public

    Because they are not restricted to usage by specific businesses, open APIs (also known as public APIs) can be used by anyone. You may need a subscription to give you access to the API depending on how frequently you use it, although there are other APIs that are completely free to use. Once you’ve sorted out your access, any software developer can use the API to make changes and transfer information more easily between various software for several purposes. 

    Image sourced from mailchimp.com

    4. Composite

    By taking the responses of multiple programs and streamlining these onto one platform, composite APIs are essential for business and personal use. Or, vice versa, a composite API allows you to make requests of multiple platforms simultaneously. It is helpful for omnichannel management, tracking customer interactions, online faxing and purchases across various platforms. These tend to require little input from developers and are set up for anyone to use.  

    How to Use an API

    • Choose Your API

    As you may have gathered, APIs can be used for several purposes. When choosing your API, look for something relevant to the business that helps you complete the tasks you already do. The software and tools you use may have recommended APIs to try, or there may be APIs that similar businesses use. Do your research to ensure your API performs the right functions and works with your rephrasing tool, calendar software or other add-ons you use. 

    If you’re getting used to APIs, you may want to start with a free option. It means that if it doesn’t work as you hoped, you’ve not lost anything by trying. Many APIs have a free trial period or a free subscription tier with the basic functions, so you can get a feel for the API and decide if it works for your business. When you’re confident in your choice, you can invest in the other subscription tiers that tend to allow for additional users and added functionality.

    • Find Your API Key

    An API key identifies you as the user, authenticating your actions using the API and tracking your usage. It is crucial to have, particularly with subscription-based APIs, as without it you may not be able to perform certain actions, or your users of the API may be limited. Even if your API of choice is free to use and publicly accessible, there still may be an API key to keep your information and preferences stored and linked between your platforms. 

    Image sourced from developers.google.com

    Your API key may be issued as you sign up for the service, so remember this and ensure those in your business who need it can access it. Otherwise, you may need to request or pay for an API key, although this should be clear when you sign up for your chosen API. To increase your API security and avoid your preferences being altered, keep your API key private and limit who has access to it. If your account is hacked, you may need to request a new API key. 

    • Read the Instructions

    It can be easy to overlook the documentation and instructions an API comes with, assuming you’ll get the gist through practicing and by actually using it. Although this may be true to an extent, you could be missing out on useful functions or not using the API as effectively as possible. Likewise, you could get yourself into a mess, not properly setting resource requests and limits, leading to more issues for your business when using the API in the future.

    Set aside time to read the instructions and documents for your API or divide the workload between your management team. You may discover it comes with setup instructions or useful tutorials you can use with the rest of your teams. As you introduce more people to the API, the instructions ensure everyone uses it in the same way. It prevents confusion for your teams and enables them to build their confidence with the API more quickly. 

    • Set Up Your Requests

    Depending on the API, there may be suggested requests for you to set up or you may have to create and code your own. Following the instructions from your API can help with this, allowing your in-house developers to reach their full potential within the API and informing you of the coding structure to use. Nonetheless, there are plenty of tutorials online covering how to set up your API requests without relying on coding expertise.   

    Image sourced from developer.paypal.com

    Just because a request is possible doesn’t mean it’s always relevant to your business. Consider why you’re using an API and what you want it to do once you’ve set up your requests. If you’re new to using APIs, start with a few basic requests and build on these as you gain confidence and experience, using CI/CD best practices to ensure it runs well. It allows you to become familiar with using each request and ensure it works in the way that you intended it.

    Are You Ready to Use APIs?

    As technology progresses and software is developed, having APIs in place is becoming more helpful. Being able to communicate between applications can streamline your virtual receptionist service, incoming video calls and outgoing messages, for example, as well as accelerate cloud-native application development. Having one place to make your requests and display information from multiple platforms gives you more control in managing your tasks.

    If you’re still new to APIs, you don’t have to start using them for everything immediately. Take your time learning to use them for specific functions, getting familiar with them, and enabling your teams to adjust to using them. From this foundation, add new APIs or requests as they’re needed, personalizing them to your business and the tasks you complete. Over time, you’ll gain confidence in using APIs and build a strong network of requests to run your business effectively.