devopsy.kinsta.cloud

Category: Doin’ DevOps

  • Six Mainframe DevOps Predictions for 2023

    Six Mainframe DevOps Predictions for 2023

    DevOps, or the automation of application development and hand-off to operations, is more prevalent than ever on the mainframe. As we begin 2023, below are six predictions for what the coming year will bring. The composite themes will undoubtedly be speed, alignment and experience.

    1. Enterprise DevOps Will Break Down Silos Across Core Systems

    DevOps practices will continue to expand beyond cloud and distributed systems to include more core systems than ever before. Core platforms, including the mainframe, are the functional backbone of mission-critical applications that drive the world economy. In a recent IDC survey, 82% of organizations reported taking steps to prioritize using the same application development tools across distributed and mainframe teams. 2023 will continue to see a rise in enterprise DevOps that will bring down the silos between platforms. As core system workloads increase, organizations will see the benefit of aligning platforms such as mainframe and distributed to realize the full benefit of their DevOps initiatives.

    2. Growth in AI/ML as Key Components for Measuring DevOps Performance Metrics

    The value of analytics will increase as organizations emphasize the use of key performance indicator (KPI) data to measure the performance and maturity of DevOps pipelines. In this way, organizations will not only gain more insights into their pipelines, but will also be able to proactively manage the data in real-time. They will be able to adjust loads as needed and create smart pipelines with advanced error handling. Organizations will leverage benchmarks within the analytics to see how they compare with their peers.

    3. Cross-Functional Pipelines Will Create Hybrid Automated Everything

    This will enable the cloud, core systems and data to deliver a more holistic view of “platforms, processes and people.” Silos will finally disappear. Automation will become a key priority in this effort as organizations seek to free up time for developers to innovate and achieve greater velocity, quality and efficiency. A single integrated and connected pipeline will emerge that automates the creation and testing of applications in a single flow. The rationale of prioritizing this alignment between distributed and core systems includes the reuse of best practices, workflow simplification, cost-effectiveness, application integration and streamlined training.

    4. DevOps Will Embrace Platform Engineering and Site Reliability Engineering (SRE)

    Platform engineering is the next evolution of DevOps, taking a DevOps platform and turning it into a self-service product to improve the developer experience. It treats DevOps as a product and allows organizations to create an end-to-end offering that serves developers, operations and platform teams. SRE focuses on the “Ops” side of DevOps, specifically how to automate operations capabilities. This is vital to the DevOps mission since it provides the data that allows organizations to manage what they can measure.

    5. DevSecOps Will Play an Increasingly Central Role

    Security must become a central part of the toolchain and a “first-class citizen” in the pipeline. Static application security testing (SAST), also known as white box testing, along with dynamic application security testing (DAST), also known as black box testing, will be further integrated into processes to enable security teams to scan large loads at rest or in real-time quickly and efficiently.

    6. Git-Centric Enterprise Source Code Management (SCM) Strategy Will Grow

    Git has become the de facto standard for SCM for distributed application workloads. In a recent IDC survey of industry professionals across 11 countries and multiple industries, 87% said they will migrate all or some of their mainframe source code to Git over the next three years. This means Git and Git-native development will become important capabilities for mainframe DevOps companies to support. Organizations will increasingly prefer implementation approaches and tools that offer flexibility in both scope and pace.

    The techniques highlighted in these predictions are, naturally, related. They point to an ever-increasing capacity for efficiency and quality that will enable core and distributed technologies to work better together.

  • WTH? WFH is 6× Pre-Covid ¦ Plus: Agile Sucks (Redux)

    WTH? WFH is 6× Pre-Covid ¦ Plus: Agile Sucks (Redux)

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Working from home is here to stay, and Agile is still a failure. (more…)

  • Benefits and Challenges of DevSecOps for Business

    Benefits and Challenges of DevSecOps for Business

    Almost every day, there is a new tactic or technique discovered that hackers can use to disrupt a company’s systems, obtain critical data and information or steal money. Often attackers look to exploit vulnerabilities in code to carry out their attacks. Ironically, it’s usually a small piece of code that helps a business perform very simple tasks that can become the root of this serious issue (e.g., logging, report service and glue for application). In fact, it only takes one exploitation, vulnerability or human error to cause a data breach that, on average, costs $4.35 million. Some experts projected that by 2025, these breaches could cost a total of $10.5 trillion. Therefore, CEOs and other corporate executives should reflect on these incidents to ask themselves what would happen if someone entered their systems to exploit code and what it could mean for their company.

    The Problems That a Business Faces

    In traditional development practices, security serves a ‘gating’ function. Security checks are performed prior to releasing an application to production and, if issues are found, security stops rollouts. This can have disastrous ramifications.

    The unknown can be frightening, but that’s where DevSecOps can help. DevSecOps incorporates security into every step of the software development life cycle (SDLC) from requirements to architecture and design, coding, testing, release and deployment. By automating and integrating security practices into the software development life cycle, development teams can react to vulnerabilities sooner, automate security checks and proceed into production with a more reliable and secure product.

    The benefit is felt when a tactical vulnerability is discovered and the DevSecOps practice is already in place to ensure that it can be remediated with limited impact on the business.

    The Business Benefits of DevSecOps and Best Practices

    Streamlining the SDLC and including security checks (often automated) in the process early in the development cycle can identify a problem before it can negatively affect the bottom line of the development effort and the business. Having a vulnerability remediated early in the development cycle is an order of magnitude less expensive than one discovered just prior to production.

    DevSecOps works best in an organization where Agile practices have been adopted to swiftly enable continuous integration, deployment and scalability. The road to streamlining and automating these practices can be long, but when effectively applied, DevSecOps best practices reduce costs for the company and accelerates time to market.

    For DevSecOps to be effective, security must have a seat at the table when requirements are gathered and architectures are planned. This integration of work practices ensures that risks are identified early and can be mitigated well before an application is launched in production.

    Using that same connection with operations, security procedures should be established to feed new vulnerability discoveries into the pipeline for remediation. However, implementing DevSecOps isn’t a magic fix and it won’t happen immediately. But why can it be so hard to implement?

    Overcoming the Challenges of DevSecOps

    There are many difficulties when it comes to implementing DevSecOps. Here are two of them:

    1. Cultural Shift:
    Leading with a DevSecOps approach requires a huge culture shift within the organization that challenges the way many departments operate today. Many employees might find it difficult to drastically change what they’ve been doing for years. Another roadblock is the belief that better protection slows down processes and restricts innovation. Quick code production is a goal for developers who want to meet the demands of businesses, while on the other hand, security teams are focused on making sure the code is secure.

    Thorough training for both security and development experts will help overcome some cultural obstacles but integrating the goals and objectives of both teams will push the adoption of DevSecOps practices. Organizations will begin to see security align to faster time and flexibility of solutions while developers will begin to adopt a security-first mindset.

    2. Complex Tool Integrations:
    Most DevOps toolchains are produced by different vendors. Teams select source code management, continuous integration/delivery (CI/CD), build tools, binary libraries, code review and problem monitoring solutions based on their unique needs. Adding security tools into that pipeline can create a challenge for ensuring the best results for both teams.

    Security analysis in the development pipeline is done with tools that perform software composition analysis (SCA), static application security testing (SAST), and some form of dynamic testing. Integration into the pipeline of these tools is significant and creates difficulties for developers. The developer must know the intent of the scan and what to do with the problems they uncover. It is important that developers have an accurate understanding of where the problem arose and what the issues mean. However, combining and comparing the results and data of many vendors’ resources might be challenging.

    The best course of action would be to consolidate your solutions. This will not only make things simpler for the developer and the organization, but it may also reveal threats that the organization wasn’t previously aware of.

    Overcoming these obstacles is not an easy task, but it is possible. Once a DevSecOps approach is accepted and fully implemented across your company, you can expect code to be developed with fewer bugs and security risks. The cost of deploying code will also eventually decrease, and at a pace that helps the organization maximize its return on investment. Overall, systems created within this process will be significantly more flexible and capable of adjusting to modern-day threats and change in the midst of a digital transformation.

  • Dev of core-js Will Flip Table ¦ Another 451 PyPI Maldeps

    Dev of core-js Will Flip Table ¦ Another 451 PyPI Maldeps

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Denis Pushkarev is fed up with core-js freeloaders, and hundreds more malicious packages found at PyPI. (more…)

  • FinOps & ITAM Must Team up to Cut Cloud Spend

    FinOps & ITAM Must Team up to Cut Cloud Spend

    Ahead of its Wisdom NA 2023 event taking place in Florida March 21-22, Rich Gibbons from the ITAM Review explores the relationship between FinOps and IT Asset Management when it comes to managing software costs. With on-premises revenues in decline, will the major software publishers respond by increasing policing and enforcement of their licensing rules in the cloud? Are cloud audits ahead in 2023? And will a marriage of convenience between FinOps and ITAM see us through?

    It’s already clear that, in 2023, corporate spending will be under the microscope more than ever. With software publisher price increases, rising energy bills and a global recession all contributing to the need for businesses to focus on cost, IT–and particularly software–is a prime place to focus. Concentrated efforts to monitor and manage software spending present a fantastic opportunity to materially improve an organization during these difficult times, enabling it to weather the storm and emerge from it lean, strong, and heading in the right direction.

    Annual spending on public cloud is predicted to reach $809 billion (IDC) by 2025, so ensuring this money is spent as efficiently and effectively as possible must become a key corporate-wide priority for every business.

    It’s Not All About Reduction

    One important aspect to realize is that, in the modern cloud age, cost management efforts shouldn’t be all about cost reduction. Rather, it is more appropriate to focus on spend efficiency. With cloud computing as a driver of digital transformation which enables organizations to offer new services to new audiences, it’s completely understandable that your cloud bill may increase; the important thing is whether the value to your business has risen commensurately.

    If your cloud bill rises by $1 million and your revenue rises by $1.5 million because you’re reaching more customers and/or have a new product line–happy days. If, however, you’re seeing your bill increase without that associated revenue increase, then that is a sign of spend inefficiency; you’re spending more for no return. This will likely be due to resources that are over-provisioned, under-used and/or incorrectly architected.

    Who’s Involved?

    The management of on-premises software such as Microsoft, Oracle, IBM, etc. has long been the domain of the software asset management (SAM) team or IT asset management (ITAM) team and their remit quickly grew to incorporate software-as-a-service (SaaS) products such as Adobe Creative Cloud, Microsoft 365 and Salesforce alongside SQL Server, Oracle DB and IBM Websphere.

    More recently, with the massive and continued growth of infrastructure-as-a-service (IaaS)/platform-as-a-service (PaaS) cloud environments, the discipline of FinOps has experienced considerable growth and become the de facto strategy for managing public cloud spending for many enterprises.

    While the two areas may seem separate, the growth of hybrid infrastructure means the two disciplines must learn from each other and work together to deliver the best overall results for a business. As John Donne said in 1624, “No man is an island,” and the same applies to teams managing corporate assets–what one team does (or doesn’t do) often impacts the other.

    Let’s take a look at some of the ways this collaboration can pay off in the real world.

    Azure Hybrid Benefit

    This is a perfect example of how regular, clear communication between ITAM and FinOps benefits everyone. Most enterprise organizations purchase their Microsoft volume licenses via an enterprise agreement (EA) and one of the characteristics of this agreement is the mandatory inclusion of software assurance (SA). This suite of extras includes a range of benefits such as new version rights, disaster recovery rights and, most pertinent here, the Azure Hybrid Benefit.

    Azure Hybrid Benefit is an SA benefit that allows you to allocate your existing on-premises licenses to cover portions of your cloud costs in Azure and on-premises hybrid infrastructure. It is currently applicable to:

    • Windows Server Azure virtual machines
    • SQL Server Azure: Virtual machines, managed instances, databases
    • Azure stack hyperconverged infrastructure (HCI)
    • Azure Kubernetes Service (AKS)
    • Red Hat Enterprise Linux (RHEL)
    • SUSE Linux Enterprise Server (SLES)

    Each of these scenarios can help an organization reduce their cloud bill, make better use of their overall Microsoft spend, and potentially use higher-level services–all increasing their return on investment (ROI) and spend efficiency. Microsoft claims savings of 50% for Windows Server and 85% for SQL Server are possible (see here), although your mileage will, almost undoubtedly, vary.

    However, while enabling the Azure Hybrid Benefit is, in many instances, as simple as ticking a box when deploying the cloud resource, that is far from the only requirement. First of all, there is a need to know how many applicable on-premises licenses you currently own and what your future plans are for renewals.

    Then you must be aware of the various licensing rules that pertain to the range of Azure Hybrid Benefits and understand their implications for your specific environment. Rules and usage allowances differ between editions, such as standard/enterprise/data center, while certain benefits may not be used concurrently. Also, given Microsoft’s penchant for regularly updating and changing licensing rules, this understanding needs to be frequently reviewed and any changes highlighted.

    Furthermore, given the direct link between on-premises licenses and cloud resources, changes at either side may have a knock-on effect. To keep hybrid spending as efficient as possible requires strong processes, capable discovery/monitoring tools and clean lines of communication between the ITAM and FinOps teams to keep things running smoothly:

    Example One:
    During the Microsoft Enterprise Agreement renewal process, a decision is made to reduce the number of SQL Server Enterprise licenses on which Software Assurance is renewed. This will require the Azure Hybrid Benefit to be removed from certain cloud workloads, resulting in increased cloud costs that need to be mitigated in other ways.

    Example Two:
    There is a blanket policy to activate Azure Hybrid Benefit for all applicable workloads in Azure. A new project is spun up consisting of dozens of Windows Server VMs and SQL Server instances which surpasses the number of on-premises licenses available; ITAM needs to be notified so they can purchase new licenses to ensure continued license compliance and, in most cases, keep spending at a minimum.

    Two Sides of the Same Coin

    In a hybrid environment, spend management and license compliance are often interlinked. So far, the software publishers have been relatively hands-off when it comes to policing and enforcement of their licensing rules in the cloud, but that could change at any point. Given that we’re already seeing the impact of the recession with layoffs across several major software vendors (Microsoft, Google) and Microsoft’s FY23 Q2 operating income dropping, traditionally on-premises software vendors such as Oracle, Microsoft, IBM, et al. may seek to realize untapped revenue in the cloud through license non-compliance audit penalties. While the examples above look at Microsoft licensing, the ability to use on-premises licenses in the public cloud exists with most software publishers and so, too, do the risks.

    A close relationship between ITAM and FinOps with regular and comprehensive data sharing and a clear understanding of each other’s priorities will be integral to the growth and development of any business using software and cloud services. Ensuring the best use of existing assets, enabling the most cost-effective cloud spending and reducing the risk of unexpected budget hits are all fundamental aspects of ITAM and FinOps collaboration.

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

  • The Evolution of DevOps: Developer Productivity and Platforms

    The Evolution of DevOps: Developer Productivity and Platforms

    This article is part two in a series of three on the rise of platform engineering and its role in improving the developer experience. Read part one here.

    Developer experience is business-critical in organizations of all sizes and across all industries. In the first article of this series, I make the case that the cloud-native developer experience will be shaped and eased not only by platform engineering but also by the vital support of DevOps and/or PlatformOps teams. This flies in the face of the recent and somewhat controversial assertion that DevOps is facing extinction. In fact, it’s possible that DevOps is more important than ever, even if the role of DevOps has changed in the era of cloud-native development, supported by centralized developer platforms.

    Business stakeholders who depend on reliable, stable, scalable and secure software shipping fast and consistently understand the business case for an integrated DevOps team, and most developers and their teams understand the challenges of coding, shipping and running cloud-native software without the guideposts offered by a platform (and the DevOps team). The complexities of Kubernetes and microservices (and their contingencies) make getting to productivity difficult, which is why developer platforms are touted as the magic-bullet solution. But these platforms don’t build and maintain themselves, and the concept hasn’t quite reached the level of maturity at which developer platforms are available as commercial, out-of-the-box offerings.

    Developer Platforms: Who Paves the Developer Path?

    DevOps is not dead and claiming that it is ignores the need for the surrounding, supporting roles that pave the developer path. DevOps is evolving, in some cases into PlatformOps, and keeps workflows flowing and manages operations that support developers’ ability to ship their work into the world.

    Who paves the developer path? It’s actually a cooperative process between developers and DevOps/site reliability engineering (SRE) teams. In discussions with DevOps and SRE leaders about cloud-native development, one trend was a throughline: DevOps and SREs continue to play an instructive role in helping guide developers to realize the possibilities of self-service through supporting platforms.

    The level of full-service ownership this amounts to for developers varies depending on the organization and its goals. But the role of DevOps is still clear. For developers, there is a significant learning curve, and DevOps can help clear the way to the centralized developer platform. This platform, assuming all goes as planned, will not only improve the developer experience but also relieve DevOps teams of the firefighting that has been typical of their job until now. Paving the path provides an opportunity for DevOps/SREs to both develop better operational support mechanisms for developers as well as engage in more long-term and strategic operational work.

    DevOps Ways: Unlocking Developer Productivity via Developer Platforms

    Helping unlock developer productivity is one aspect of powering a positive developer experience. And the shift to a developer-first platform model reinforces the business commitment to the developer experience. It becomes defined by its optimized tools and workflows, which make up developer platforms. The platform approach also supports wider adoption of cloud-native development across larger organizations and broader industries beyond the more niche applications we’ve seen, thanks to clearer guideposts and abstractions.

    But becoming dev-first doesn’t kill off ops, which has been one recent point of contention. In fact, the three ways of DevOps continue to be critical:

    ● The First Way: Flow/Systems Thinking
    ● The Second Way: Amplify Feedback Loops
    ● The Third Way: Culture of Continual Experimentation and Learning

    Quoting industry luminary Gene Kim, “The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department—this as can be as large a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g., a developer, system administrator).” Essentially, it doesn’t matter who constructs the platform as long as they are thinking about the entire value stream, starting with customer requirements which, for an internal platform, are driven by developers.

    The Second Way is focused on creating right-to-left feedback loops. To quote Kim again, “The outcomes of the Second Way include understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where we need it.” For platforms, this hints at embedding both developers in platform teams and ops in development teams.

    The Third Way is focused on creating a culture that fosters two things: Continuous experimentation, taking risks and learning from failure and understanding that repetition and practice is the prerequisite to mastery. The platform you build today won’t be the platform you need tomorrow. This is why the ‘big bang’ approach to building platforms doesn’t work. Think big, start small and iterate fast. This is something DevOps is designed to do.

    In supporting the cloud-native paradigm, DevOps is far from dead. It’s a shifting discipline that involves a focus on centralizing workflows and infrastructure to improve the developer experience and reduce their cognitive toil. This toil stems from developer guesswork, and DevOps is best positioned to remove that obstacle. If we concede that developer experience is central to business success, and devex depends on being able to code, ship and run quickly and safely, DevOps is the fixer who enables crucial self-service access for developers and, as we will explore in the third and final part of the series, “platforms” the developer experience.

  • Taking the Modular Route

    Taking the Modular Route

    In today’s world of continuous software development and integration, removing bottlenecks and increasing efficiency is of utmost importance. One surefire way to improve this efficiency is leaning into modularity–or ‘taking the modular route.’ In software engineering, modularity refers to building complex products or processes using individually distinct functional modules.

    An analogous way to describe this is thinking of modularity like you would Lego. Every Lego can connect to every other Lego using the same approach. But the way you put them together differs, from simple constructions to magnificent architectural creations, even though they’re made using components that connect in the same exact way.

    Put simply, modularity is a deployment strategy that allows for quick configuration changes through standardized methods. In that sense, software development is much more manageable when it is modular.

    A Way to Address Growing Complexity

    Modularity has been key in helping to build complex business solutions. Before developers started using this approach, the risk of a single update or software release taking down the program was very high–and common. Fortunately, modules became popular and combatted that issue with their parallelity, allowing multiple teams to work independently without affecting each other’s work.

    This cut down on the inevitable complexities that would emerge from the common issue of too many cooks (developers) in the kitchen (working on an application). And this applies all the way up the ladder to business leaders as well, who are able to now choose from various modules and plug the module into their ecosystem according to their specific requirements.

    The feature-independent modules can be regularly updated and tweaked without affecting other parts of the ecosystem. This way of continuous development looks seamless to the end user without any downtime. And developers often employ prewritten modules, which conserves resources and makes modularity successful.

    Promoting Innovation

    Developing modules individually greatly increases the rate of invention. Each department or business could delve further into its operations by focusing on a specific module. Having many teams focus on the design of a given module fostered numerous parallel solutions. Modularity, in this way, helps innovation happen more quickly within organizations–teams are given the ability to expand to a marketplace model where third-party developers can create their custom modules that are easily integrated.

    If you want to see a perfect example of modularity’s positive impact on innovation, take a look at how quickly the mobile app marketplace has grown. Thanks to modularity, third-party developers created their own modules based on set standards, which gave way to innovation and the mobile app marketplace. External developers can develop custom modules and plug them into a separate system.

    Take a look at your phone and it’s evident in Apple’s App Store. It has thousands of apps–the majority of which are from external developers. If an ecosystem supports modularity, custom module development is made available to partners and clients, which not only expands the product scope but also helps to fast-track the launch of new products.

    Standardization and Scaling Up

    Modularity’s standardized function is a crucial advantage for developers. The same modules can be used across different businesses, which reduces the need to design custom solutions. During the development phase, which is fast-paced and demanding, this standardization improves product quality while reducing errors and oversights.

    The business flows are designed with the same plug-and-play approach–giving the flexibility to change them with almost zero to minimal code changes. The plug-in nature of modules also allows complex systems to be scaled up with new modules.

    During downtime, they can reduce the number of modules, which reduces costs and gives teams immense flexibility to manage that cost and resources over time. This is invaluable for changes like government compliance requirements that continually go into effect. Plug-and-play modules enable IT teams to maintain the continuous business processes.

    Ease of Maintenance

    Because of the standardization of the modular route, maintainability is considered an inherent part of system design. The ease with which a system is kept up efficiently and easily is crucial to IT teams, and modularity gives way to the maintainability of a product. New fixes or updates can be easily integrated in the independent modules and diagnosing quickly helps in reducing the turnaround time.

    The end business user also does not need to worry about the internal details of the modules. They should have a high-level knowledge of what the module does and can integrate it into their system without being bogged down with knowledge of the inner workings.

    Reuse, Reuse, Reuse

    Reusability is one of the biggest advantages of taking the modular route because the same functional unit can be used in various instances, making for rapid development and, ultimately, faster time-to-market.

    One real-life example of this is a company that needed a new connection to onboard new customers, which required custom configuration on the client’s end. Every time a new integration needed to be created, the process repeated. As any developer will tell you, the method was not scalable in the long run–and had massive maintainability issues. This is where the modular approach saved the day. The company designed a system where a new client connection could be configured using pre-existing modules and reused for multiple clients.

    Collaboration and Interchangeability

    Developers are not allowed to be one-person bands–the work requires constant teamwork across departments and teams. Modules are perfect for this–multiple teams can work simultaneously on different modules, which cuts down the laborious development cycle. Teams can work in different design patterns and develop unique solutions to improve product quality.

    Interchangeability goes hand in hand with this–the business user can change an existing module and use a different module with minimal effort to the business flow. Options are then increased for the end user, and they can choose from many different solutions.

    The modular pattern is not entirely new, but its success relies on the collective effort of IT teams and business leaders to do their part in designing and following a standard software framework. Only then will developers be able to take the modular route and deliver innovative, quality software for organizations across industries around the world.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com 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:

    Monster.com

    AppZen
    San Jose, California
    Software Engineer
    $165,000 to $190,000

    Indeed.com

    Safeway
    Pleasanton, California
    Lead DevOps Engineer
    $147,500 to $206,600

    Dice.com

    Amazee Global Ventures, Inc.
    Broomfield, Colorado
    DevOps Engineer
    $140,000 to $150,000

    SimplyHired

    WEX, Inc.
    Remote
    DevOps Engineer
    $127,000 to $169,000

    LinkedIn

    Apple
    Newport Beach, California
    Site Reliability Engineer/DevOps
    $115,000 to $177,000

  • Data Mobility: Why it’s a Must and How to Achieve It

    Data Mobility: Why it’s a Must and How to Achieve It

    The workplace has undergone a drastic change, and so has the way companies need to move their data. Wondering how those two points are connected? Let’s dig in.

    It’s clear that remote work is here to stay: Just over a quarter (26%) of U.S. employees are currently working remotely, and a staggering 36.2 million Americans will work remotely by 2025. Naturally, this huge influx of remote (and hybrid) workers has necessitated changes in IT infrastructure. It has changed how people work, engage with their corporate databases and applications and what they expect from their corporate technology infrastructure.

    In the past, companies migrated their data every four or five years when they refreshed their storage infrastructure. CIOs and storage experts now think differently about how data centers are built and optimized. Important questions all companies should consider are: Does it make sense to build out storage capacity ahead of the need? Do we really plan to have our databases and applications hosted on-premises over the next five years? One CIO recently told me, “If you aren’t talking about your future in the cloud, you aren’t paying attention.”

    The Need to Migrate Data More Frequently

    The shift toward a more flexible storage architecture, even in a hybrid cloud environment, has created the need to migrate data much more frequently, fueling the demand for data mobility. Robust data mobility is essential in today’s world: Companies need to securely and efficiently move their data to accommodate a strategy that accommodates both on-premises and cloud; even multiples of these. Data mobility constraints can’t dictate the success of an organization’s digital transformation. Moving data to the best location based on an organization’s goals—whether they’re related to cost, manageability, performance or some other factor—is critical.

    Another critical factor to consider regarding data mobility: The data must always be accessible to the end user, regardless of when or where it’s moving. In the age of remote work, people are working based on their own unique schedules, so data must be accessible at all times.

    In fact, data from Microsoft recently revealed that 30% of its employees choose to work at night. Gone are the days when systems could be offline for data migration during “non-working hours.” Remote work demands continuous data access so employees can stay productive and work at their convenience.

    With this in mind, here are three key steps companies can take to achieve data mobility.

    1. Strategy
    When determining where to store data, consider who will need access to the data, what performance level will be required and what the cost will be for each data storage location. Is everything best contained in a single public cloud? Is a multi-cloud strategy or a hybrid cloud storage environment a better approach? We often talk about data mobility and data migration interchangeably, but not all data migration solutions can continuously move data between storage environments.

    Organizations must also determine how they will move their database and applications to the new environment. If this step isn’t addressed during the strategy stage, it can become an afterthought and create problems down the road.

    2. Deployment
    Once an organization has determined which storage environment best fits its needs, it’s time to move the data from its source to its destination. A single, one-time migration involves moving the data from its current location to a new location and stepping away until the next migration. Data mobility solutions are ideal when data needs to move back and forth, requiring data mobility solutions (e.g., moving from on-premises to a multi-cloud environment).

    During this step, organizations must ask the following questions and plan accordingly to minimize any negative impact: How long will this migration take? How secure is the data in transit from source to destination? How disruptive will the transition be to end users? What will the impact on the organization be? How much manual effort is required?

    Sometimes moving data can make applications sluggish, affecting productivity and resulting in workers overloading the help desk with inquiries about what’s happening. Data migration tools can help organizations tackle deployment efficiently, securely and without disruption to end users (again, continuous data access is vital).

    3. Assessment and cutover
    After the data has arrived at its new destination, it’s time for the cutover process (i.e., running the application in its new location and removing the old storage). Cutover is when problems can arise if everything isn’t mapped correctly. Organizations need protections in place to ensure there is no risk to their operations should something go awry during the process. Additionally, minimizing the impact of this transition for end users is vital, so organizations should also be doing whatever they can to reduce downtime.

    Companies can consider leveraging a data mobility tool that can synchronize in the background without impacting users. So, while users are still working on the old site, new infrastructure can be updated simultaneously, requiring just seconds to minutes of cutover. This time can be planned for off hours so that it’s minimally disruptive and doesn’t require notifying employees.

    The technology landscape is constantly changing, and so are storage vendors’ offerings. Companies need solid data mobility to pivot at a moment’s notice to take advantage of newer, better and more cost-effective capabilities. Data mobility gives companies the flexibility to stay competitive, and data migration tools that allow continuous data access keep workers productive.