devopsy.kinsta.cloud

Category: Enterprise DevOps

  • Automation Relation

    Automation Relation

    One thing that is absolutely true: This latest iteration of IT improvement is about automation. Whether making DevOps more automated, working on any of the various “X-as-code” movements or implementing AI, the idea is to create what one vendor portrayed as a “human-free zone.” A space where automation does everything that needs doing.

    And the one question we all need to be asking now is simple: Where do we want that human-free zone in our organization?

    The answer is inevitably, “In more places than you think,” for a wide variety of reasons. Let’s cover what you should be thinking about when answering this question – because this change is already upon us and we’re doing a lot more without so much as an approval.

    1. Anywhere that compliance is on the line and the action doesn’t risk crashing systems.
    2. Anywhere the process being performed is so rote that any member of the team can do it and everyone thinks of that process as a distraction.
    3. Anywhere that time is critical. Think of incident response to a DDoS or zero-day attack.

    This is a very basic starting point. From here, we want to move into “anywhere we have a static list of steps to perform.” So, the above points would include things like, “If a new employee is in the marketing department, they belong in the Marketing security group. If they are further working on marketing for new products, they belong in the Marketing for product development group.” But eventually, you want to get to, “This app communicates on port 12345, so that port must be accessible, run the script to open that port.” The decision about “Should this port be open?” can then be shifted left to have more involved discussions about options and necessity. Our current world already does some of that; automation will make it standard.

    And that’s what we’re getting. We’re in a world where some standardization is enabling automation, and automation is demanding that we figure out more standardization. And it is all good. There is a lot we do in IT that a trained monkey could do, and we need to let a trained system do it. The more time we have, the more problems we can solve … So let’s keep freeing up that time.

    And keep rocking it. Your time is valuable precisely because you keep the organization running. Freeing up that valuable time just makes you a greater asset to the organization and makes your job less boring as a bonus.

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

    Monster.com

    SnapLogic
    San Mateo, California
    Infrastructure Engineer
    $183,310

    LinkedIn

    Metropolitan Transit Authority – NYC
    New York, New York
    Cybersecurity Officer – DevSecOp/Cloud Infrastructure
    $144,500 to $191,000

    Dice.com

    Flexion
    Remote
    Azure DevOps Engineer
    $140,000 to $170,000

    Indeed.com

    Woven Teams
    Remote
    DevOps Engineer
    $116,000 to $147,000

    SimplyHired.com

    Raytheon Missile and Defense
    Schriever Air Force Base, Colorado
    Senior Software Engineer
    $75,000 to $161,000

  • Orgs Shift Toward Centralizing Automation Initiatives

    Orgs Shift Toward Centralizing Automation Initiatives

    A survey published today found that 75% of respondents recognized that automation silos hamper their ability to unify cloud operations across functions.

    Conducted by CloudBolt Software, the survey polled 350 senior IT and DevOps leaders at organizations with more than 3,000 employees. On a positive note, the survey found 57% of respondents were starting to pursue a more centralized approach to automation, with a total of 88% acknowledging that having all previous and new automation centralized for the entire organization would ensure compliance, bolster security, enable business continuity, encourage reuse and reduce risk.

    Rather than taking a more holistic approach, well over half of respondents (57%) reported automation efforts are limited to specific silos. On average, organizations are employing 27 different automation tools their organizations have deployed, using one or a few as they see fit, with little to no consistency across teams. More than half (55%) of respondents said they have four or more separate automation teams, with 95% noting that each of those teams operates in their own silo.

    CloudBolt CTO Rick Kilcoyne said that lack of continuity clearly creates inefficiencies and redundancies that conspire to raise the total cost of IT. The challenge is that each team tends to favor one approach to automating a silo with little to no regard for a larger overall strategy to create an automation standard, he said.

    That approach also creates issues whenever a member of one of those teams leaves an organization, he noted. In fact, the survey found 77% of respondents reported that continuity is at risk any time a vital member of the team leaves.

    CloudBolt has been making a case for a federated automation platform that can be invoked either via application programming interfaces (APIs) or a graphical user interface (GUI) that provides access to low-code tools. The goal is to make the platform equally accessible to DevOps teams or IT administrators that tend to lack programming skills, and do so in a way that doesn’t require individual teams to replace their automation platform of choice. Instead, each of the automation platforms can be programmatically invoked via a central framework, said Kilcoyne. That approach eliminates any political debate over the potential need to replace one team’s favored automation platform with another, noted Kilcoyne.

    Regardless of who is accessing the platform, most organizations would be well-advised to develop a center of excellence for automation, he added.

    DevOps teams have always been committed to ruthlessly automating as many IT processes as possible, but in many cases, that has resulted in a plethora of automation tools being employed. In effect, automation may have become too much of a good thing. One approach to regaining control over those platforms is to create a platform engineering team that centralizes the management of DevOps workflows.

    Regardless of approach, Kilcoyne said the most important thing for any team to do before automating an IT workflow is to first understand how to manually set it up. Too many IT teams are trying to apply automation to processes they don’t really understand with mixed results, he added.

    The one thing that is certain, especially with the rise of artificial intelligence (AI), is the management of IT is going to become more automated.

  • Things We Should Acknowledge, Part Two: Skills Are Less Relevant

    Things We Should Acknowledge, Part Two: Skills Are Less Relevant

    This is perhaps the toughest issue for all of us to acknowledge: The longer you are in the space, the more skills you have filled out on LinkedIn (or wherever you are tracking your career for HR reps to look at) but the skills you possess today are, by definition, a subset of the skills you will possess even a couple of months from now if you change roles. Note that I said “change roles,” not “change employers.” The fact is that we use an insane number of tools in the development, DevOps and operations environments, and we’re addicted to adding new ones (that might be a hint about part three of this series). Changing roles within a company can involve minor changes, or it can take you to a whole new environment where no one cares that you are a Java genius; they want to know how fast you can pick up Python and be truly productive. Or they nod at your talk of configuring servers and ask if you can do that with Ansible on containers. It’s just not as important anymore for most employees to have a specific skillset. That’s a major contributor to the problems I talked about in part one.

    Of course, there are roles in IT that involve far less change. Email administration, for example, isn’t all that different from the way it has been since, well, forever. We have changed how/where the server is configured and many orgs have added SSO or multifactor authentication, creating new issues, but it’s all evolutionary. When NoSQL systems came out, it looked like a major change in DBA work, but it really wasn’t. Within a year, reality put SQL over top of NoSQL stores and DBAs kept chugging along.

    But DevOps has impacted both development and operations in profound ways. We pretty much standardized on Java, with all of its warts, because it was object oriented, general purpose and could be compiled if needed. Though embedded largely stayed with C, there was no serious competition in the enterprise for Java and Java-like (.NET) languages. Knowing them meant you could do everything but real-time/embedded development jobs—and even some embedded work shifted to Java as prices for miniaturized compute power dropped.

    But that changed. The inflection point was JavaScript, and from there, we went a little bit crazy. When JavaScript took off, full-stack developers needed to know one front-end and a couple of backend languages. Other languages still existed—the staying power of both Perl and PHP is somewhat surprising to me; they’re both good languages but have limitations. But still, no serious competition. But Node.js took JavaScript to the server, Ruby was popular for backends, Python came along for quick scripting … And now we have apps written in those and a dozen more languages floating around.

    I chose languages to fit the whole story into a blog because they see less change than the operations side, where we’ve gone from annual big releases to rolling deployments updated frequently and all the support tools changed in the process. Infrastructure has changed, data stores have changed, mobility has changed, UI targets have changed—basically, it’s a chaotic mess.

    And you’re in the heart of it, keeping the data flowing and the org running. It’s astounding, and you deserve more kudos than you’re likely getting. So approach hiring differently. Some orgs are already there, but skill-based hiring is still too prevalent. Hire broad technical knowledge and a desire to know more. As someone I know honestly said in a job interview once, “No, I never used it, but it is just another programming language. I’ll be productive in a week.” She got the job and delivered as promised. For all but those few corner-case roles, hire for potential and achievements and skills will follow.

  • 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

    NerdRabbit
    New York, New York
    DevOps jobs
    $120,000 to $150,000

    LinkedIn

    Tata Consulting Services
    Sunnyvale, California
    AWS DevOps Engineer
    $105,000 to $130,000

    Monster.com

    VANET, Inc.
    Irvine, California
    Software Engineer
    $100,000 to $300,000

    SimplyHired

    Renaissance
    Remote
    DevOps Engineer 2
    $100,000 to $125,000

    Indeed.com

    GEICO
    Remote
    Senior DevOps Engineer
    $82,000 to $185,000

  • npm is Scam-Spam Cesspool ¦ Google in Microsoft Antitrust Thrust

    npm is Scam-Spam Cesspool ¦ Google in Microsoft Antitrust Thrust

    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: The npm registry suffers spam infestation, and Microsoft makes Google sad. (more…)

  • The Right Tool for the Job: Alerting Edition

    The Right Tool for the Job: Alerting Edition

    In high-tech, we have a terrible predilection for finding a good tool and abusing it until we hate it. I’ve written several “Use the right tool for the job” articles and posts over the years, most notably an examination of trying to make one programming language (or another) into an all-purpose solution. We’re thankfully past that … for now. But we do the same thing across all of IT in general and DevOps in particular. Consider what we did to Jenkins when DevOps was coming of age. It went from a great innovative tool to a bloated monster we tried to use to automate just about everything short of making coffee in between integration runs. Fact is, Jenkins is still a good tool in the CI space; everyone started hating it because it was over-used. It’s a terrible tool when used for things other than what it’s good at. Imagine that. We can make the same statement about, well, everything. “A car is a terrible tool when used as a life preserver,” is a good example of some of the absurdity that makes us hate good tech.

    The 2023 edition of this phenomenon came up on a for-fun video call with some friends this weekend, and talking about it made me realize how bad it has become. Thus, I give you the point of this post:

    Slack is not your documentation tool. It is not anything but an efficient alerting tool and maybe a stand-in communications tool for short-term convos.

    I see it all over the place. “Oh, we discussed that on Slack.” That’s great, where did you document it? Because honestly, some of the companies I deal with have busy enough Slack channels that if the conversation happened more than an hour ago, it will never be seen again.

    Slack, and a few similar tools, are astounding alerting channels, offering an opportunity to notify when events occur, and we really should continue to reap the ease-of-use and massive alerting benefits that these tools offer. But don’t confuse that with long-term anything. Because it is not.

    Alerting to Slack needs to be one piece of a larger puzzle. Making sure that whatever was alerted on was also logged somewhere (either by the alert mechanism or by whatever tool spawned the alert), and for a whole array of issues that are alerted on and many of the conversations that happen in Slack, long-term documentation needs to be created.

    So this is a lot of words to remind you of what you already know: Slack can enable quick communications, alerting and innovative solutions by having broader discussions without cramming everyone into a conference room. But it is not a documentation tool in any way, and it needs to be part of an integrated solution that uses the right tool for the job. Security alerts, for example, better be ending up in the SIEM (they are in every organization I’m aware of; just using that as a glaring example).

    And keep rocking it. Just make sure while you’re running at 500 miles per hour to keep up with Agile and DevOps speeds, you are capturing the stuff that will be important in six months or a year somewhere that people can actually find it. And use each tool to do what it’s best at. Convenience is almost never the best selection criterion for a tool to solve a given problem.

  • Salesforce Spring 2023 Release: Out With the Old, A Lot of the New

    Salesforce Spring 2023 Release: Out With the Old, A Lot of the New

    Salesforce is the connector and enabler of so many critical business functions. But that doesn’t mean it doesn’t come with its headaches. The environment is so complex that it really takes a conscious, focused effort to properly leverage all that Salesforce has to offer, as well as stay up-to-speed on everything that’s new and evolving.

    The Salesforce spring ‘23 release brought a lot of change. Some old tools disappeared and new products, dashboards and automation tools were introduced that admins will have to adapt to. There’s a lot to catch up on.

    Combing through the 600+ pages of release notes, there are three main themes represented in the spring release that will be useful to the entire organization, from DevOps and RevOps to sales and marketing teams, including: 1) new admin and developer tools and dashboards, 2) doubling down on low-code/no-code with enhancement to Flow and 3) commitment to security and permissions best practices.

    Admin and Developer Updates

    From an administrator’s and developer’s perspective, there are some exciting new features that will undoubtedly improve DevOps’ day-to-day. For instance:

    • Flows – allows you to migrate your old automations.
      • Connect to external data source (beta)
      • Support for lookup fields
      • Reactive screens (reduce the number of “Next” clicks)
      • Removal of “Iteration Limit Exceeded” governor limits
      • Element descriptions are now visible on the canvas
      • Migrate to Flow from Process Builder

    • DevOps Center – Still in V1, but it provides developers with a new interface.
      • Getting on the software development life cycle bandwagon so we can all say goodbye to change sets – finally!
    • Dashboards – Now you can insert text and graphics around charts.
      • Collections – organize reports and dashboard into logical collections that are free from their folder hierarchy. While they will still “live” in their folders, they can be accessed from a collection as well.
      • Add image and text components in your Dashboard to make better experiences with additional information, descriptions, instructions or whatever you want.

    These updates are not only useful for DevOps but, from an executive viewpoint, are extremely useful to showcase the business’s data with a clearer perspective. In other words, the new dashboards have more options to provide additional context and insight. In general, the user interface is not only more organized but can be navigated at a significantly faster rate than before.

    Doubling Down on Flow

    As the old adage goes, “Out with the old, in with the new;” Salesforce will be retiring the automation tools Workflows and Process Builders and converting them to Flow. The reason Salesforce is making this move—and ultimately forcing users to Flow—is because Workflows and Process Builders don’t have the flexibility or functionality that Flow does. Flow can create automation and provide great screen experiences that derive a far greater bandwidth of context and situational logic. The additions made to this much-anticipated migration tool will help administrators convert their current automation into Flow with less stress and hassle than rebuilding them all from scratch.

    So what is the timeline for this migration? Salesforce plans on blocking the ability to create new Process Builders in the Summer ‘23 release but has admitted that it’s not a hard date and will look at the success of customers’ migrations to Flow and feedback from the community. They have not yet announced a date for complete retirement but expect it to come sometime in 2025. That said, users should start doing this now. With any major change to your Salesforce environment, a plan is always recommended, especially with such a huge migration like this one. Given the amount of data and processes most organizations already have in place, we suggest taking time to strategize and test your migration prior to releasing it directly to Flow to make sure your order of operations for your automation is clear and follows best practices. Analyze your business processes and confirm with your users that these processes are still accurate.

    Commitment to Security

    As organizations lean more on Salesforce as their primary business operating system, Salesforce is becoming a critical piece of infrastructure rather than just software that businesses consume. It is also the “build-and-develop” nature of Salesforce that has more companies treating Salesforce as software they build rather than just software they use. The ripple effect is that as companies build within Salesforce, more developers are responsible for deploying and managing data. With that comes the responsibility for security and compliance.

    This has traditionally been handled as an administrative task, but now, Salesforce has created the tools for true enterprise infrastructure security and data management with permission sets and permission set groups. Even though permission sets have been around a while, the introduction of permission set groups and the growing need to transition permissions into more complex structures have changed the way permission sets are being consumed. Permission sets were previously used for basic exceptions to the permissions provided by profiles, but now they are front and center, providing even more organizational capability with Permission Set Groups (and their muting capability, but that’s a different story).

    Salesforce has taken note and announced the partial end of permissions within profiles as they lean into the new, better way to manage permissions. Profiles won’t be gone entirely, as they will still be needed for basic defaults, i.e., defining users’ default app selections. However, while Permission Sets will still have the responsibility for what apps you have access to, it will be the Profile that states which one is your default. This is also true for other types of assignments where there needs to be a single source of truth, like page layout assignments.

    Salesforce said they will be enforcing this plan in 2026 but are beginning to make sure everyone gets on board now by releasing great new tools to make this transition smoother, including user access policies and access to Permission Sets when adding new fields (currently only available for profiles). For large organizations, three years is just around the corner when it means implementing major overhauls in technology and philosophy to the business. While some are heading to building Permission Sets based on each object, I’d recommend basing them on features or functional areas to have the most control and the clearest overview of your new vast area of Permission Sets.

    Next Salesforce Release

    Overall, the spring ‘23 release was jam-packed with content to boost productivity, strengthen security, enhance the user experience and improve the overall business functionality. There are two Salesforce releases still to come in 2023, and I’ll be dissecting them both to highlight the most critical changes that can help you better your business. I’m looking forward to seeing what the summer ‘23 release has in store – any predictions on what Salesforce will come up with next? I’ve got a few guesses…

  • Tabnine Extends Generative AI Alliance With Google

    Tabnine Extends Generative AI Alliance With Google

    Tabnine has extended its alliance with Google Cloud to advance the adoption of generative artificial intelligence (AI) to automate the writing and testing of code.

    The generative AI platform provider has already developed its own large language model that is hosted on Google Cloud. Tabnine is now also committing to leveraging the large language model that Google is developing to automate software development life cycle processes.

    Brandon Jung, vice president of ecosystems for Tabnine, said it’s apparent that application development and deployment teams will be making use of multiple large language models across SDLC workflows. Not all those large language models will be developed by one single platform provider, he noted.

    Rather than being dogmatic about large language models, Tabnine plans to make it possible to invoke multiple models via application programming interfaces (APIs) that are integrated with development environments, he added.

    The Tabnine platform supports multiple programming languages, including Python, Java and JavaScript and is designed to be integrated with integrated development environments (IDEs) such as Visual Studio Code and Jetbrains. The company also previously integrated its code completion tool with the GitLab continuous integration/continuous delivery (CI/CD) platform. The overall goal is to make it easier for developers to automatically write code based on custom models using approved source code hosted in a secure private repository.

    Generative AI creates a large language model that assesses the probability of what the next line of code will be based on what has preceded it. It’s not likely DevOps teams will be replaced as generative AI is extended across workflows, but the overall size of those teams might shrink as it becomes possible to do more with fewer people. At the same time, the barrier to DevOps adoption will also fall as AI platforms make it simpler for more organizations to embrace DevOps best practices.

    The challenge will be making sure the data collected to train AI models is of a high enough quality to ensure the desired outcome. Organizations will need to find a way to apply generative AI to data models that have been validated by DevOps teams.

    One way or another, it’s only a matter of time before generative AI capabilities are applied more broadly. Platforms such as OpenAI’s ChatGPT are only the tip of an iceberg that impacts almost every manual process, including software development and deployment. The issue will be determining how quickly those innovations will become practical enough to employ.

    In the meantime, it is already apparent generative AI platforms are having a significant impact on the rate at which code can be developed. Inevitably, that means the amount of code moving through DevOps pipelines at any one time should increase significantly. DevOps teams should expect generative AI technologies to be applied both before and after application code is built and deployed, noted Jung.

    In the meantime, the biggest issue is, arguably, keeping up with a rate of generative AI innovation that is occurring faster than many organizations can absorb.

  • Data APIs: Realizing the Future of Data Warehousing

    Data APIs: Realizing the Future of Data Warehousing

    Data is the currency of business in today’s digital economy, with organizations collecting mountains of data from their customers, products and services. Enterprises are increasingly turning to data warehouses to store this valuable enterprise data and to make it useful and actionable. Data APIs–both GraphQL and REST–are emerging as a tool to power frictionless and high-quality integrations between applications/services and data in enterprise data warehouses. But what exactly is driving this shift toward using APIs on top of data warehouses? In this article, I will talk about the drivers behind the rise of data APIs on data warehouses, challenges with current approaches to building, operating and scaling data APIs and how organizations can address those challenges.

    The Rise of Data APIs

    Data APIs enable organizations to create powerful integrations between applications without having to go through lengthy development cycles or write complex code. As a result, businesses can deliver improved user experiences faster than ever before by quickly connecting disparate applications and services together using intuitive REST or GraphQL endpoints. Because these endpoints are standardized across multiple systems (e.g., REST or GraphQL), developers don’t have to learn new languages or coding techniques every time they want to connect two different applications together. This makes it much easier for developers to work with multiple systems simultaneously while still ensuring that all applications remain connected via one interface–the API endpoint itself.

    Challenges With Current Approaches

    Despite all these advantages provided by Data APIs, there still remain a few challenges that organizations need to consider when building out their own solutions. For example, many existing approaches require manual setup processes, which can be extremely time-consuming and tedious for developers working with multiple systems at once. In addition, many existing solutions only allow for limited query functionality, which means that more complex queries may not be possible without additional coding or manual setup processes being performed. Finally, some existing solutions require an extensive amount of organizational resources in order to build out a full-fledged solution—time that could be better spent on more important tasks like product development or customer service initiatives.

    How Organizations Can Address These Challenges

    Fortunately, there are now tools available that make it easy for organizations to quickly build out powerful data API solutions with minimal effort required from their developers or IT staff members. These tools provide pre-built templates that can be used as a starting point for any integration project while also allowing users to customize their own solution based on specific needs and requirements without having to write any code themselves. Additionally, these tools allow users access to advanced query functions such as joins across multiple tables so they can get the most value out of their databases without compromising either speed or security either. Finally, these tools also include powerful monitoring capabilities so users can ensure that their data APIs remain running smoothly at all times, no matter how much traffic they receive.

    Benefits of Using an API for Integrating Cloud Data Warehouses

    When it comes to integrating cloud data warehouses into your application or service, there are several advantages that come with using an API as opposed to traditional methods such as manual coding or ETL tools:

    • Increased Flexibility: By leveraging an API, you are able to access data from multiple sources quickly and easily without having to manually code every integration yourself. This also allows your application or service more freedom when it comes to accessing additional data sets in the future; all you need is an existing API connection in place.
    • Improved Security: Since APIs are designed specifically for secure communication between different systems, they offer enhanced levels of protection against malicious attacks such as DDoS attacks or unauthorized access attempts. You can also add additional layers of security by implementing authentication protocols like OAuth or JWT tokens on top of your existing API connection.
    • Enhanced Performance: APIs can be designed with specific performance optimizations in mind; this means that you can create custom solutions tailored towards the exact needs of your application or service which will ultimately result in improved end-user experiences and higher engagement rates from customers who interact with your product or service regularly.

    Data warehouses have become an essential part of modern digital businesses due to the sheer amount of valuable enterprise information they store. However, traditional approaches can often lack the flexibility or scalability needed in order for businesses to stay competitive in today’s ever-changing market environment. This is why smart organizations are using data APIs on top of them for quick integration among disparate applications/services along with advanced query capabilities.

    By leveraging tools designed specifically for this purpose, companies can easily overcome current challenges associated with building out their own solutions while still getting maximum bang for their buck when it comes down to successful implementation and operation over the long term.