devopsy.kinsta.cloud

Category: DevOps in the Cloud

  • The Practicalities of Open Sourcing

    The Practicalities of Open Sourcing

    I’ve been deeply immersed in the world of developer products for the past decade, and let me tell you, I’ve been quite the open source enthusiast. Over the years, I’ve had the pleasure (and occasional pain) of shepherding open source projects of all shapes and sizes. It’s almost become a rite of passage in some teams – the moment when your APIs and libraries step into the spotlight. After all, customers want to know what kind of software is going into their code concoctions. But, let’s be real, I’ve also witnessed open source used as a bit of a smoke-and-mirrors exercise. So, if you’re contemplating the daring act of open sourcing your projects, here are some things to know before you set out.

    Manage Your Expectations of External Contributions

    If I had a penny for every open source manager disappointed by unrealistically high hopes of a flood of external contributions, I’d have enough pennies to… well, still not meet those expectations. The truth is that the majority of open source projects never witness a bustling community of external code contributors. Just because your software is popular doesn’t guarantee open source success. Open source is like nurturing a garden; it takes time and effort to grow. Building a community involves shaping your APIs, fine-tuning functionality, defining boundaries and managing expectations. Expecting an avalanche of external contributions in the early days is a recipe for disappointment.

    OSS can be Intimidating

    While developers generally relish the idea of sharing their work with the world, I’ve stumbled upon situations where junior engineers were a tad shy about coding in the public eye. In some cases, we’ve had to delay open sourcing because engineers wanted to tidy up their work before unveiling it to the world. Especially if your team is a mix of early-career engineers, it might be easier for senior team members to offer coaching and conduct code reviews in a more private setting without the intimidating public glare.

    Issue Triage and the Support Price Tag

    In theory, maintaining a public issue tracker is distinct from open sourcing the code itself. In practice, these two are closely linked. Opening up your product’s priorities to the public means putting them on display alongside real interactions and feedback from customers. This doubles the importance of being responsive to customer issues, efficiently triaging them, and setting the right external expectations. For successful open source projects, this is a genuine labor of love.

    The Need for a Private Mirror

    There comes a time when you need to work on something in private, perhaps in preparation for a grand launch event. Unfortunately, last time I checked, GitHub doesn’t offer private branches. You might find yourself wrestling with the challenge of setting up a private mirror. What happens when you’re juggling a significant launch on an internal mirror while simultaneously managing customer bug fixes on the open source repository? Mirrors are like trying to keep two squirrels synchronized – challenging.

    Saying Goodbye to Obscurity

    Some software on the internet relies on obscurity for its security. Open sourcing it would be like sending hackers an engraved invitation to a party they don’t need directions to.

    Unfriendly Dependencies

    If your project is tangled up with third-party libraries sporting licenses that are less open source-friendly than a cactus in a desert, you’re in for a headache. I sincerely hope you don’t run into this, as unfriendly licenses often come hand in hand with unfriendly people.

    Navigating the Ecosystem: Dealing With Dependency Upgrades

    Open source codebases often face a common challenge – the relentless pressure to keep dependencies up to date. This is especially true for libraries and APIs embedded in customer applications, where managing transitive dependencies and supporting older versions can be a delicate balancing act.

    Teams typically adopt one of two approaches. Some isolate these dependencies in a separate namespace to avoid conflicts, while others enforce a policy to always use the latest versions. Regardless of the chosen method, open source projects frequently encounter external contributions aimed at upgrading dependencies. Handling such contributions publicly, and sometimes declining them, can be a tricky task.

    Maintainers must navigate this terrain diplomatically, explaining that the proposed change might not be suitable for all users by paraphrasing, “You’re not our only customer, and this could affect many others.” This balancing act showcases the challenges of maintaining open source projects in a dynamic ecosystem.

    Unexpected Benefits

    Now, let’s not forget the unexpected perks I’ve stumbled upon during my open source adventures. After all, I’ve done enough complaining.

    ● Modernization: Open sourcing often nudges you to modernize your build and deployment pipelines because, frankly, it’s easier to get them right than to get them wrong.

    ● Privacy and security: Open sourcing can make addressing questions about privacy and security a breeze. In an era of regulatory crescendo, it’s your golden ticket to showcasing your data-handling ballet. It’s like saying, “Hey, world, check out our moves!”

    ● Building trust with customers: I’ve found some outstanding team members through successful open source projects.

    ● Trust in open standards and code: Organizations are increasingly placing their trust in open source software. Your larger customers might care about this more than you’d imagine.

    And that’s a wrap, folks. Best of luck with your open source journey!

  • API Management: A Weak Link in the Cloud-Native Chain

    API Management: A Weak Link in the Cloud-Native Chain

    Managing APIs is like navigating unfamiliar terrain during a road trip: There’s an old way and a new way to do it, and the new way is just better in many cases. For API management, the old way of doing things involves practices like writing proprietary scripts, manual transaction monitoring and relying on individual employees to take charge of managing specific APIs – leading to more manual work, slower release processes, slower incident recovery and lower reliability. It’s akin to navigating a highway using a paper map, stopping at gas stations to ask for directions and crossing your fingers that you end up at your intended destination.

    The new way of managing APIs looks like this: Using declarative configurations, automated processes and stateless APIs, teams scale and centralize the tasks of configuring, monitoring and updating APIs. They also deploy API changes several times a day, and they can instantly mitigate incidents in production.

    It’s like navigating with a GPS: A simpler, faster and more flexible approach that gets you where you want to go with much less hassle and risk.

    To prove the point, allow me to walk through the reasons why traditional API management strategies fall short for modern environments, then discuss what it takes to manage APIs better.

    What is API Management?

    Let me begin by defining what I mean by API management.

    I’m referring to all of the practices, processes and tools that businesses use to support the APIs their workloads depend on. API management encompasses API design, development, monitoring, testing and security, as well as making updates to APIs after they are in production.

    These tasks are important, of course, because APIs are everywhere today. They handle 83% of internet requests, according to Akamai, which means that keeping APIs documented, updated and monitored is a critical requirement for virtually any organization that deploys Internet-connected applications.

    Without an efficient and scalable means of managing APIs, it becomes difficult not just to defend against challenges like security risks involving APIs but also to guarantee a positive developer experience. The more time and toil your developers have to invest in API management, the less time they have to do the things they want to do and that matter most to the business – like developing cool apps and bringing them to market.

    The Pitfalls of Traditional API Management

    APIs are not new, and most teams that support them have long had API management practices in place. However, in many cases, those practices were conceived in the era when monolithic application architectures and bare-metal servers or virtual machines dominated the IT landscape. They weren’t designed for today’s cloud-native, software-defined, distributed-everything world.

    As a result, traditional API management falls short in modern environments in several key respects:

    ● Slow change management: When you are continuously pushing out updates to apps and APIs, you need an API management strategy that can handle continuous change. Traditional approaches can’t do this. They are too human-intensive to keep pace with rapid change.
    ● Lack of reliability: If you manage API configurations manually, you face a higher risk of introducing changes that accidentally break something. And if that happens, fixing the issue is slow because you have to reconfigure everything by hand.
    ● Slow recovery speed: When you experience an incident related to an API – such as a latency increase due to a misconfigured API – recovery is slower because it’s difficult to trace the surface-level problem back to its root cause, given the lack of a central source of truth for tracking the API’s status and revisions.
    ● Lack of scalability: Traditional API management uses imperative configurations that are stored in stateful databases, which have to be provisioned for each API you want to deploy. That works if you have just a handful of APIs to manage, but it’s impossible to scale if you need to scale to support dozens or hundreds. It also creates particular challenges if you have geo-distributed teams and infrastructure.
    ● Lack of modularity: Conventional API management architectures are not modular or composable, making it difficult to reuse configuration components between APIs. Instead, engineers are forced to “reinvent the wheel” every time they need to configure a new API or move an existing one from dev/test to production.
    ● Lack of standardization: Traditional APIs typically depend on proprietary technologies. As a result, they’re difficult to integrate with modern stacks that are based on widely used tools like Kubernetes, OpenTelemetry and Git.
    ● Poor collaboration: Documenting APIs and sharing monitoring insights between teams is also challenging when configurations are imperative and there is no single source of truth that all stakeholders can refer to when tracking the status of an API.

    These challenges lead to a nightmare for teams tasked with Day 2 operations, meaning those that support APIs after they are in production. Slow, inefficient and unscalable management processes lead to struggles in detecting and fixing problems with API performance or security, as well as in updating APIs. And again, they hamper the developer experience by forcing developers to devote time and energy to deciphering APIs and versions to use, finding up-to-date documentation, and so on. As a result, developers whose main job is to write software, not manage APIs, become burdened by API management requirements.

    A Better Way to Manage APIs

    The good news is that a better world is possible – at least when it comes to API management. For modern apps and environments, API management should be rooted in the following principles:

    ● Composability: Your API management stack should be composable so that you can pick and choose from different ingress controllers, monitoring and analytics tools, load-testing solutions and so on. You shouldn’t be bound to a rigid, inflexible “stack.”
    ● Statelessness: Stateless API management, which frees APIs from dependency on stored configurations, enables scalability, simple rollbacks and consistency across environments because you can deploy APIs anywhere with minimal provisioning.
    ● Automation: The more you automate the processes involved in API management, the faster you can implement changes and the lower your risk of mistakes and inconsistencies due to manual management.
    ● Immutability: The underlying infrastructure that powers your API management stack should be immutable so you can replicate it easily and quickly – a benefit during processes like troubleshooting following a rollback.
    ● Auditability: You should be able to maintain a timestamped log of every change to your API that documents when changes are made, who made them, why they happened and what the potential implications are.
    ● Open and standards-based: The ability to monitor and manage APIs using open, standardized tools and frameworks – such as OpenTelemetry and kubectl – also leads to consistency and simplifies collaboration between teams. In addition, API contracts should be standardized using specifications like OAS.
    ● Efficient incident response: When you discover a performance problem or failure linked to an API, you should be able to troubleshoot and resolve the issue quickly without having to chase down documentation or find the one person at your company who understands how the API works.

    When you manage APIs according to these principles, you escape the tedium and inefficiency of traditional API management. By extension, you can easily support the many APIs that tie your cloud-native environments together.

    The Role of GitOps

    Going a step further, a declarative, stateless, automated approach to API management also enables GitOps, meaning that you can manage APIs via declarative configurations that you store in Git repositories.

    This practice also leads to greater reliability (thanks to consistent, repeatable and scalable configurations), collaboration (because Git serves as a shared, central source of truth for API configurations and workflows) and efficiency (due to the ability to automate and customize deployments using Git-based triggers and actions).

    Conclusion: API Management at Cloud-Native Speed

    In a world where more than half of existing applications are cloud-native and a majority of new apps will leverage cloud-native principles, traditional API management just doesn’t work for these new platforms. It leads to change management processes that are slow and unreliable – exactly the opposite of what businesses need to thrive in a dynamic, cloud-native world. It also slows down recovery, leading to lower levels of reliability and higher risk for the organization. On top of this, it’s tedious, inefficient and unscalable. So yes, cloud-native API management is currently broken.

    We need a radical new approach to API management with one goal in mind: Automate Day 2 API operations with a modern approach. Modern solutions should be rooted in stateless, declarative configurations, open standards and Git-based automation. They must enable change management with high reliability and instant recovery, so you don’t have to worry about API management becoming the weakest link in your ability to innovate quickly and with minimal risk.

    We envision a new world where managing APIs is no longer a burden that developers and platform teams must bear but instead a process that helps teams innovate as quickly as possible, no matter how complex the API architectures they are working with. We also want to help businesses bring products to market faster, as well as troubleshoot incidents more quickly and with less effort.

    Ultimately, we want to empower organizations to take full advantage of cloud-native technologies and paradigms by adopting a cloud-native approach to API management.

  • F5 Looks to Streamline Application Networking

    F5 Looks to Streamline Application Networking

    At its AppWorld 2024 conference this week, F5 announced a software-as-a-service (SaaS) edition of its NGINX application networking portfolio, which are now all available under a single enterprise license.

    Shawn Wormke, general manager for NGINX, said NGINX One will eliminate much of the friction enterprise IT teams currently encounter when implementing NGINX Plus, NGINX Open Source, NGINX Unit, NGINX Gateway Fabric and the Kubernetes Ingress Controller the company provides.

    As part of that effort, F5 is also now making available a unified console across its application networking portfolio that promises to streamline the management of the F5 application networking portfolio.

    Currently available under an early access program, NGINX One creates an as-a-service platform through which enterprise IT organizations can invoke and pay for these capabilities on an as-needed basis, said Wormke. The overall goal is to reduce the total cost of application networking by eliminating the need for IT teams to integrate the various elements of NGINX One on their own, he added.

    In general, application networking has become more complex with the rise of cloud-native applications based on microservices. By reducing the cognitive load required to network those applications, it becomes simpler to make network operations a more natural extension of DevOps workflows, noted Wormke.

    Most organizations have some level of experience with application networking using proxy servers, but as application environments have become more complex, the need for gateways and ingress controllers to provide these capabilities at scale has become more apparent. As a result, more IT organizations are starting to revisit how they are structured. There may always be a need for dedicated networking specialists to manage the physical network underlay, but as other networking services become more integrated with DevOps workflows, responsibility for some networking services is starting to shift further left toward DevOps teams that will either deploy these capabilities themselves or take advantage of a SaaS platform such as NGINX One. The overall goal is to be able to dynamically provision application networking services without having to wait for a network administrator to provision them.

    There are, of course, a lot of approaches to application networking that are now emerging. Regardless of how application networking evolves, however, the rigidity that has characterized the delivery of network services for decades should finally start to fade away. Today, outside of a cloud computing environment, it’s still common for IT teams to provision virtual machines or Kubernetes pods in hours only to wait days or even weeks for network connectivity to be provisioned. As IT environments become more hybrid and more workloads are pushed to the edge, there is a clear need for a more agile approach.

    Each organization will need to decide how best to approach application networking across legacy monolithic applications, microservices and event-driven applications at a time when IT environments have become much more complex to manage. The challenge, as always, is reducing as much friction as possible without unduly raising the total cost of IT to a point where it becomes unsustainable.

  • 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 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:

    Dice.com

    Travelers
    Hartford, Connecticut
    DevOps Tech Lead
    $133,500 to $220,300

    Indeed.com

    Lawrence Berkeley National Laboratory
    San Francisco, California
    Identity and Access Management DevOps Engineer
    $126,900 to $214,140

    SimplyHired.com

    Workday
    Pleasanton, California
    Software Development Engineer
    $112,500 to $204,000

    LinkedIn

    IBM
    Denver, Colorado
    DevOps Engineer
    $110,100 to $161,100

    CareerBuilder.com

    Cognizant Technology Solutions
    Oakdale, New Jersey
    DevOps Manager – Technology Modernization
    $95,500 to $212,600

  • Why Startups are Betting Big on Low-Code/No-Code

    Why Startups are Betting Big on Low-Code/No-Code

    It is exhaustive — from infrastructure to app delivery, from data to applications — to modernize your practices, processes and providers to ensure you have the underlying foundation to take advantage of whatever comes next.

    Two or three years ago, apps created through low-code/no-code platforms were not usually as detailed under the surface as software developed from scratch, yet they sufficed for certain purposes. There was even a clear distinction between software developers and everyone else out of necessity because software development was incredibly difficult to master.

    But now, as we head towards more advanced AI, the SaaS-based low-code/no-code (LCNC) platforms empower businesses to create software exponentially faster and cheaper than a code-based approach.

    The future, therefore, of startups in this changing business landscape becomes even more competitive, taking into account the increasing importance of customer-centric UI modeling, data product development and cutting-edge technologies like machine learning and deep learning.

    High-Value Acceleration

    Applications built through traditional software development can take months or even years to launch. If you create a code-based solution, it’s also easy to blame others and there’s a lack of understanding if it’s not well-documented. “Low-code no-code functionalities can change this dynamic,” says Dr. Ingo Mierswa, an industry-veteran computer scientist and founder of Altair RapidMiner. “The visual workflow describes what it’s doing, so people can understand it, buy into it and take ownership of the results.”

    Visual workflows can be understood and created by more people. “They make it easier to maintain and explain why anything, such as a model’s decision or a bug, has happened because the workflows are documenting themselves,” Mierswa articulates. “It would be hard to create such an explanation if you had to sift through 100,000 lines of code, especially if the code had been changed 17 times in the past two weeks.”

    You need to iterate, you will make mistakes, and you don’t want to waste time with coding non-critical things. “My big advice for all starters is to always think about what’s critical for your product. What’s your IP? What do you need to own and customize? And if coding is not that important for your product, I think going low-code/no-code is always the better way,” Mierswa shares. “It’s more important for startups because you have less resources, less time, more competitive pressure and markets are moving very quickly.”

    Everyone is a Citizen Developer

    In the early 1960s and 1970s, there was a clear distinction between software developers and everyone else out of necessity. Software development was incredibly difficult and time-consuming to learn and master. But now with the onset of low-code/no-code solutions, everyone from custodial teams to C-level executives can create and customize applications that make their jobs more efficient.

    Because no-code/low-code platforms are built on the fundamental premise. “People closer to the problem are better equipped to find simpler and effective solutions,” says Kissflow CEO Suresh Sambandam. “It’s a team sport, and accountability, the most important benefit of LCNC solutions, accelerates development and empowers even more people to collaborate the right way.”A big advantage,” Sambandam says, “is that CIOs of large enterprises can solve the IT talent shortage plaguing the industry today by leveraging expert business users who are ‘citizen developers.’ Many companies can’t avoid struggling to recruit and retain tech talent in a highly competitive market, but low-code/no-code solutions exceedingly help bridge that talent gap by freeing up the bandwidth of existing resources.”

    At the highest level, you always need people who understand the business problems that need to be solved. LCNC functionalities also empower adjacent team members — designers, product managers, data scientists and others — to take part in the different stages of development as the product takes shape.

    Reducing Technical Debt to Overcome Friction

    In an enterprise scenario, most of the core systems like ERP, CRM, SCM in the front end, as well as in the back end, are bought from standard vendors. There is NO differentiation, as all the top enterprises buy from the same vendor. On the other hand, the bulk of differentiation comes from middle-office processes that are unique to an enterprise. Sambandam points out, “Often these are business processes that require heavy domain knowledge that frequently change to adapt to the evolving business conditions and hence business users are better equipped to build these workflow automations.” He highlights that conventional software development models don’t do justice to the agility required by business users and are too complex for them to use. While business users have the domain knowledge, the system would also require integration touch points with other enterprise systems. These integrations often require deeper technical expertise.

    It is essential to create a cultural change within your organization, where it is not just about having the right tools, but also about investing in your employees and skilling them up, commented DevRev Head of Engineering Ahmed Bashir.
    It still is hard work, and there will be friction. “Overcoming friction requires creating a tighter loop across departments and managers, closing the gap between developers and customers,” he underscores. “And LCNC platforms are designed to act as a system of action, surfacing real-time information that connects work with developers, customers and product.”

    This is exactly where platforms like Kissflow, Blaze and Bubble, which support both no-code and low-code use cases come in and let business users handle the domain portion of the application (90%) and IT teams configure the integration points (10%). This greatly reduces friction between IT and business users, especially when it comes to solutions for long-tail internal workflows.

    Long-tail applications include things like approval management, creative requests, incident management, customer onboarding and IT helpdesk. “We looked at the space and decided to tackle this,” Sambandam shares.

    Long-tail apps and processes are often viewed by IT as a drain on time/resources they don’t have, yet it’s a lack of internal workflow processes automation that gum up digital transformation. “We found as we scaled the company that when you empower business users to quickly build and augment workflows that directly impact their day-to-day by giving them the tools to do so without advanced technical knowledge, they are motivated to make it happen,” he affirmed.

    Security is a Business Enabler

    The main objective of security is to protect organizations and people. Organizations prepare for potential security threats by implementing policies and ensuring they have the tools to mitigate and quickly respond to outside threats.

    However many low-code/no-code adopters do not have security expertise on their team so they rely on the LCNC platform to offer security features readily available for the apps they build. Because creating applications with custom code can lead to a variety of security issues. And such applications are difficult to secure, with the majority of tested applications containing one or more session management vulnerabilities, and others with input validation errors.

    Getting a firm handle on security means considering what to do. That sounds simple enough, but it’s surprising how many startups make blunders because of poor planning and shoddy strategies. “We’ve been looking at a trend. Companies want enterprise-level security like audit logs, SSO and other data security requirements for their apps,” commented Nanxi Liu, Co-CEO of Blaze. “Seeing this strong trend, we worked to design our platform with enterprise security and scalability in mind, since most early-stage companies do not have security expertise on their team and rely on platforms to offer advanced security features for the applications they build.”

    Make, however, no mistake — there is no best security but the best practices. “That’s part of why,” Liu says, “compliance-driven businesses like financial services and healthcare companies that require the highest level of security to build their customer portals, consider enterprise-grade no-code and low-code platforms that provide the required level of security.”

    With low-code/no-code platforms, your applications are secure with industry-standard protocols, data protection practices, and features to block unauthorized access.

    To underscore: LCNC allows non-technical people to build complex apps without needing to be familiar with traditional software logic. You don’t need computational thinking because visual components in low-code/no-code platforms automatically have the logic built-in. “And now with the mind-bending AI breakthroughs,” Liu remarks, “users can tell AI in natural language the workflow or feature they need and see it instantly created.”

  • How to Manage Multi-Cloud Infrastructure and Reduce Costs

    How to Manage Multi-Cloud Infrastructure and Reduce Costs

    It’s no secret that the public cloud has been a game changer for businesses. In today’s world, every organization is looking for ways to store data more efficiently, support agile application development and reduce the burdens associated with on-premises data centers.

    The public cloud is essential for meeting those objectives and achieving the higher degree of innovation and digital transformation that many organizations seek. While the shift to the cloud has unlocked unprecedented innovation, it has also created a new layer of complexity and sometimes unexpected costs.

    The Nutanix Enterprise Cloud Index found that nearly every organization (99%) has moved one or more applications to a different IT infrastructure in the past year, and the vast majority (86%) agree that moving applications is both complex and costly. Accordingly, 56% plan to focus on gaining more visibility into their cloud consumption and costs this year, while 52% plan to leverage solutions that minimize cloud waste.

    As Scott Sinclair, senior analyst for TechTarget’s Enterprise Strategy Group explains, “The typical enterprise now has multiple data centers and public cloud providers, and many are also using lots of different colocation facilities and multiple edge locations.” As such, “It presents a new paradigm with companies having to look at different factors and considerations like cost, portability and security because their data is no longer all locked in one room.”

    Organizations must carefully plan their cloud strategy to avoid getting bogged down by complexity and sticker shock. But in most cases, this is easier said than done. The majority of companies are not using a single environment — their infrastructure includes some combination of on-premises and public cloud resources. One of the challenges this creates is additional expenses and complexity associated with data mobility and data protection: Moving data around so that it’s available where and when it’s needed while simultaneously keeping it safeguarded requires careful planning and budgeting. In other words, data has gravity, and unless data movement and orchestration are planned, one can end up stranded when the primary location for a dataset is unavailable.

    Even companies that were born in the cloud have their work cut out for them. Managing different cloud environments might be relatively straightforward for a cloud-native organization initially, but if at some point their data needs to be relocated on-premises to address compliance, data sovereignty issues or budget, it can result in soaring costs if not properly executed.

    With this being said, here are four considerations CIOs should take into account to keep cloud complexity and costs in check from the start.

    1. Have Your Head in the Cloud but Your Feet on the Ground

    To reap the benefits of the cloud, organizations need to adjust their expectations and plan realistically. There’s a false perception that companies can run an application on AWS in the morning, Azure in the afternoon, and Google Cloud Platform at night. In actuality, multi-cloud is a medium-to-long-term strategy that occurs over months or years. Building a cloud operating model with this in mind lets organizations benefit from the flexibility of leveraging multiple clouds while avoiding the cost and complexity associated with trying to do too much too fast with the cloud. When appropriate expectations are in place, hybrid multi-cloud is achievable, affordable, and undoubtedly beneficial.

    2. Learn on Others’ Dime as Much as Possible

    There are several best practices organizations should follow as they begin their hybrid multi-cloud journey. These include things like ensuring key application capabilities have API wrappers, containerizing modern applications as much as possible so they are portable, and automating application deployments through CI/CD pipelines to avoid manual errors and reduce costs. Public clouds have been around for almost 15 years, and designing for the public cloud is now quite well understood across the industry. Still, companies need to be mindful of how they leverage public cloud for certain applications or workloads. For example, modernizing a legacy application portfolio might sound like a good idea in theory, but in reality, it is cost-prohibitive and it will not provide ROI —lift and shift is a much better option for legacy applications.

    3. Standardize, Automate and be Paranoid

    Public cloud environments are fundamentally different from traditional on-premises infrastructure, so organizations need to think about them differently—especially where security is concerned. While a fortified exterior with unfettered internal freedom might be a workable model for on-premises, the same model could spell disaster in the cloud. Host-based security approaches have become more critical in the public cloud. Automation and standardization ensure that security measures are applied consistently across all cloud resources and services within an organization and shorten the window to detect unauthorized behaviors. Organizations must also consider the non-technology aspect of this: training and education for their teams. All teams and departments must be on the same page when it comes to security so they can collaborate effectively on security-related initiatives.

    4. Build in Optionality From Day One

    The public cloud is by far the best place to begin innovation. However, as companies experiment in the public cloud and a smaller portfolio of applications gain traction, enterprises need to adjust to the reality that — for the vast majority of applications — the public cloud will always be more expensive than running them on-premises (or perhaps even another cloud). To avoid lock-in, enterprises must build in optionality for migrating their compute when needed, as well as the mechanism to move their data out of public clouds when needed. Organizations that are flush with cloud engineering talent can do this on their own, but the vast majority will require an underlying platform that’s explicitly designed for data and computation mobility.

    The perks of one platform to run all workloads across clouds, on-premises, and the edge are undeniable: From increased flexibility to optimized performance, compliance, agility and more. By heeding the advice above, companies can keep multi-cloud challenges like complexity and unexpected costs at a minimum and fuel innovation.

  • Azure Cost Optimization: A Complete Guide

    Azure Cost Optimization: A Complete Guide

    Microsoft Azure is one of the “big three” cloud providers, and is a primary part of IT expenditure for many companies. Azure cost optimization is a strategy that involves managing and controlling Azure costs to ensure efficient usage and spending. It requires a thorough understanding of where and how your resources are being used, as well as insight into the various pricing options available.

    Azure cost optimization involves implementing best practices related to managing cloud costs, such as turning off resources when not in use, choosing the right-sized resources, taking advantage of Azure discounts and more. By optimizing these aspects, you can ensure that you are only paying for the resources you need and are using them efficiently.

    Azure cost optimization is an ongoing strategy that involves constant monitoring and adjustments as your usage and needs evolve. This means that you need to be proactive and vigilant in your cost management efforts, regularly reviewing your usage patterns and making adjustments as necessary.

    Why is Azure Cost Optimization Important?

    As organizations migrate more and more of their workloads to the cloud, the costs associated with Azure usage can quickly escalate if not properly managed. This can lead to budget overruns and decreased profitability.

    By leveraging Azure cost optimization strategies, businesses can gain greater control over their Azure spending. This not only helps in reducing costs but also enables businesses to more accurately predict their future cloud spending. This can be a major advantage when it comes to financial planning and budgeting.

    Moreover, Azure cost optimization can also lead to improved operational efficiency. By ensuring that resources are used efficiently, businesses can avoid wasted spend and focus their resources on the tasks that truly add value to their operations. This can lead to increased productivity and better overall performance.

    Azure Cost Optimization Tools

    Azure provides several free tools designed to help customers optimize their cloud spending. These tools provide insights into your usage patterns, help you identify potential cost savings, and guide you in implementing best practices for cost management.

    Azure Cost Management and Billing

    Azure Cost Management and Billing provides detailed insights into your Azure spending. It allows you to track your spending by resource, location, service, and more, enabling you to identify where your money is going.

    With Azure Cost Management and Billing, you can set up budgets to control your spending and set up alerts to notify you when you’re nearing your budget limits. You can also analyze your spending trends over time, which can be useful for forecasting future costs.

    Azure Advisor

    Azure Advisor provides personalized recommendations based on your usage and configurations, helping you optimize your resources for cost, performance, security and reliability.

    Azure Advisor can identify unused or underutilized resources you can shut down or resize to save money. It also provides recommendations for purchasing reserved instances or using Azure Hybrid Benefit, which can lead to significant cost savings.

    Azure Pricing Calculator

    The Azure Pricing Calculator is a tool for estimating the cost of Azure services before you use them. You can input your expected resource usage, and the calculator will provide an estimate of the costs.

    This tool can be especially useful when you’re planning a new workload or considering a migration to Azure. By understanding the potential costs upfront, you can make more informed decisions and avoid surprises.

    Azure Monitor

    Azure Monitor is a comprehensive service that provides insights into your application performance, infrastructure, and network. While primarily used for performance monitoring, it can also provide valuable insights for cost optimization.

    For example, Azure Monitor can help you identify overutilized or underutilized resources, enabling you to make adjustments to optimize your costs. It can also help you track your resource usage over time, providing insights into your spending patterns.

    Azure Resource Graph

    Lastly, Azure Resource Graph is a service that enables you to explore your Azure resources at scale. It provides a unified view of your resources across all your subscriptions, making it easier to manage and optimize your resources.

    With Azure Resource Graph, you can quickly identify resources that are not in use or are underutilized, allowing you to reduce unnecessary spending. It also enables you to visualize your resource usage, helping you understand your spending patterns better.

    6 Strategies for Azure Cost Optimization

    Now that we are familiar with the basics of cost optimization on Azure and the tools the platform provides, let’s review some strategies that can help you optimize and reduce costs in Azure.

    1. Right-Sizing Azure Resources

    One of the simplest yet most impactful strategies for Azure cost optimization is to right-size your Azure resources. This involves matching your business requirements with the appropriate Azure resources in terms of type, size and quantity.

    Too often, organizations over-provision their Azure resources, which leads to unnecessary expenditures. By right-sizing, you ensure that you’re only paying for what you need. This can be achieved by closely monitoring your Azure resources usage, identifying any underutilized resources, and scaling them back accordingly.

    Remember, Azure provides a range of resource types, each with its own set of capabilities and costs. Always cross-verify whether the selected resource is the most cost-effective one for your specific use case. For instance, if your application doesn’t require high compute power, choosing a lower-tier virtual machine could significantly reduce your costs.

    2. Utilizing Azure Budgets and Alerts

    Azure Budgets and Alerts are powerful tools for cost management. They provide you with the ability to set a budget for your Azure spending and receive alerts when your spending approaches or exceeds your budget.

    Setting up an Azure budget is a proactive approach to cost management. It allows you to allocate your finances effectively and avoid any unexpected charges. Furthermore, with Azure alerts, you can instantly get notified when your consumption is nearing your budget. This gives you ample time to adjust your usage or increase your budget, preventing any service disruptions due to overspending.

    Moreover, Azure Budgets and Alerts are highly customizable. You can create multiple budgets for different scopes (like management groups, subscriptions, or resource groups), set your alert conditions, and even automate actions based on these alerts using Azure Logic Apps.

    3. Tagging and Resource Organization

    Azure tagging and resource organization is another crucial strategy for Azure cost optimization. Tags are user-defined key-value pairs that you can assign to your Azure resources. They help you categorize and manage your resources based on your business needs.

    By effectively tagging your Azure resources, you can gain visibility into your resource consumption at a granular level. This can help you identify any high-cost resources, track your spending by project, department or environment, and make informed decisions about cost optimization.

    Organizing your resources into logical groups can also simplify management and governance. For instance, you can group your resources based on their life cycle or purpose and apply consistent policies and access controls across the group. This not only improves security and compliance but also helps in identifying any redundant resources that can be eliminated to save costs.

    4. Utilizing Storage Tiers Based on Usage Requirements

    Another effective strategy for Azure cost optimization is to utilize different storage tiers based on your usage requirements. Azure Storage provides three access tiers – hot, cool and archive, each designed for different types of data.

    The Hot tier is for data that is frequently accessed and requires low latency. It has higher storage costs but lower access costs. The Cool tier is for infrequently accessed data, offering lower storage costs but higher access costs. Finally, the Archive tier is the most cost-effective solution for long-term retention of rarely accessed data.

    By carefully analyzing your data usage patterns and selecting the right storage tier, you can significantly reduce your Azure storage costs. Moreover, Azure offers automatic tiering options like blob-level tiering and life cycle management policies, which can further optimize your storage costs based on your data lif ecycle.

    5. Leveraging Azure Hybrid Benefit

    If you’re an existing Microsoft customer, leveraging Azure Hybrid Benefit can be a game-changer for your Azure cost optimization. Azure Hybrid Benefit allows you to bring your on-premises Windows Server and SQL Server licenses with software assurance to Azure, offering significant cost savings.

    With Azure Hybrid Benefit, you can run Windows Server and SQL Server workloads on Azure at a reduced rate, providing substantial savings as compared to pay-as-you-go prices. Furthermore, Azure is the only cloud provider that offers such benefits, making it an ideal choice for businesses looking to optimize their cloud costs while leveraging their existing Microsoft investments. Azure Hybrid Benefit is starting to support software from other companies, including Oracle and Red Hat.

    6. Regularly Reviewing and Optimizing Subscriptions

    Lastly, regularly reviewing and optimizing your Azure subscriptions is a must for Azure cost optimization. This involves keeping track of your Azure usage and costs, identifying any inefficiencies and making necessary adjustments.

    Azure provides several tools like Azure Cost Management and Azure Advisor that can help you gain insights into your Azure spending and offer personalized recommendations for cost optimization. For instance, Azure Advisor can identify idle resources that can be shut down to save costs or suggest reserved instances for predictable workloads to avail discounts.

    Moreover, consider exploring Azure Cost Management Power BI App for advanced reporting and analysis of your Azure spend. It offers a rich set of visuals and filters that can help you uncover deep insights into your cost data and drive cost efficiency.

    In conclusion, while Azure offers a plethora of services and capabilities, managing costs effectively requires strategic planning and continuous monitoring. By implementing the above strategies, you can ensure that you’re making the most out of your Azure investments while keeping your costs under control.

  • How to Make the Most of In-House Software Development

    How to Make the Most of In-House Software Development

    Let’s be blunt: Maintaining an in-house software development team can be tough. You must hire skilled developers – which is no easy feat in today’s economy, where talented programmers remain in short supply – and then manage them on an ongoing basis. You must also ensure that your development team is nimble enough to respond to changing business needs and that it can adapt as your technology stack evolves. Given these challenges, it’s no surprise that most organizations now outsource application development instead of relying on in-house teams.

    But I’m here to tell you that just because in-house development can be hard doesn’t mean that outsourcing is always the best approach. On the contrary, IT organizations that choose to invest in in-house development for some or all the work can realize lower overall costs and a competitive advantage by creating domain-specific expertise. Keeping development in-house can help organizations address unique security requirements and maintain full control over the development lifecycle and roadmaps. For businesses with specialized technology, security and operational needs, in-house development is often the best strategy.

    Managing an in-house development team presents some steep challenges. At Komprise, we have refined several practices to keep our team efficient and productive, even in a business environment that is constantly changing.

    Scaling Up

    Scaling teams up is a key challenge for in-house development teams. Finding skilled developers to grow a team can be very difficult, especially when working with a bespoke technology stack.

    There is no simple solution to this challenge, but there are steps you can take to maximize your ability to find and hire development talent. For example, we invest significantly in engaging with college students, allowing us to identify promising developers while they are still in training.

    At the same time, we invest in upskilling our developers who are already on our team so they can take on additional responsibilities. We train our engineers in the latest cloud development and security skills and knowledge. The notion of embedding security into our designs and practices is fundamental to what we do. We also rotate engineers between different teams so they learn new technologies that are important to our business. This strategy allows us to align the work for every developer with their interests and to build reusable skills within our teams. We also hold a technical brown bag three times per month where we cover issues like development for cloud and how it differs from on-premises due to costs or how to design for performance and scalability.

    Focus on Customer Value

    Figuring out which features customers want most is a constant challenge. To address it, we quantitatively track how our customers use our product – which functionality they use most often, for example, and how usage patterns vary across different customer demographics. We evolve these metrics as we develop the product. Additionally, we identify customers who are “power users” and occasionally set up calls between them and our developers to gain additional insight into what customers want. Our marketing team also conducts customer advocacy interviews with our users to learn more about what they like and don’t like.

    Looking at third-party applications and interfaces helps us gain perspective on how best to meet user needs, too. For example, we might examine how Wayfair or Amazon are evolving their UI constructs to inform how we could change our product interface in ways that better meet customer needs. We want our B2B product to be as easy to use as consumer products.

    Invest in QA

    Quality Assurance (QA) operations are distinct from development operations, but if you want a successful in-house development team, you need a great QA team, too. Our QA engineers complement our in-house developers by helping them to deliver the highest-quality product, while also strategizing over how best to handle scale and efficiency challenges. In addition, we’ve invested heavily in QA automation, allowing us to test our applications thoroughly while keeping our team lean and efficient. This ensures that as our product feature set expands, our ability to test the entire product does not increase and we can maintain a monthly release cadence. We use test harnesses to simulate error and failure conditions, by injecting failures into the system or making our network experience a brownout or a blackout. You can’t automate every software test, but you can automate most of them, and QA automation is one of the key ingredients in effective development operations.

    Leverage AI Strategically

    AI is not the solution to every development challenge, but when used properly, AI can accelerate development and help in-house developers work more efficiently. Using AI tools to churn out code has become a hot use case for AI in development since the introduction of solutions like Copilot. AI can be a very useful solution, but the quality of the results it delivers hinges on the quality of the data it ingests. Inhouse development teams working on AI applications have much to consider from the data perspective. To leverage unstructured data, they need ways to find it across data silos, enrich it with new metadata as needed to support search and leverage AI tools like Amazon Macie and Rekognition to further refine the data.

    Optimizing In-House Development for the Long Term

    The importance of keeping in-house development teams happy and productive is likely only to increase as the tasks they work on grow more complex and as new paradigms, like those driven by AI, change the way developers work. The more IT organizations and enterprises can upskill their existing developers and empower them with the right tools and processes to succeed, the better they can leverage their teams to build products and features that bring value to the business.