What is Splunk Phantom Admin?

If you work on a security team, you probably deal with complex security infrastructure and a range of technologies from multiple vendors. You’re likely exposed to unquantified risk stemming from a constantly expanding attack surface and escalating volumes of threats. And like everyone else, you have limited resources to defend your entities. There’s is never enough budget or people. Fortunately, there is a better way. Force multiply your efforts with a Splunk phantom security orchestration, automation, and response platform.

Phantom integrates your team, processes, and tools together so you can bring your best defense forward. It allows you to automate repetitive tasks. So, you can focus on other mission-critical issues. It helps you up-level how you manage events and cases and improve collaboration and training across the team. Phantom allows you to triage every by executing routine workflows in seconds or minutes instead of hours or more if done manually. It helps you make your SOC operations repeatable and auditable. Teams are able to manage events and cases the same way, every time, regardless of the person working on them. You’re able to accurately measure and reduce risk. And finally, you can demonstrate measurable impacts on your key performance metrics like MTTR. See what phantom can do for you. Get started now with the phantom community edition.    

What are the benefits of Splunk Phantom Admin?

From the beginning, we have learned many sorts of Splunk platforms series like Splunk core developer, enterprise security, cloud admin, and IT service intelligence. This time we are meeting with Splunk phantom. Every software has its own performance, duties, and responsibilities with great impact then query raises that what about the software defensive security and how the software maintains their accuracy with higher scalability. With this overview, there are certain benefits related to Splunk phantom certified admin such as: 

• Create security for the management system
• Highly integration process
• Security work flowing system
• Automation security system
• Advanced threat catching actions

Why we should learn Splunk Phantom Admin?

Nowadays, this trending IT organization with the higher escalating tools. We are working with different technologies at a scale of interactions. If we are using the software too much then we need threat detection analysts and security system services. Then, a query comes as that why we should learn Splunk phantom and become certified. The most reason is that to automate and accelerate the process like shortage of IT security professionals, a large number of security point solutions, challenges of unstructured data, the investigative approach, people & processes, and workflow of threat mitigation timeline. And the admin facing common security operations challenges such as resources, products, alerts, static, speed, and costs. So, if you move along with Splunk phantom then you can evaluate delivering quality intelligence, improving the efficiency and efficacy of operations, enhancing incident response, and improves reporting and knowledge capture. As a Splunk phantom certified admin, you can make your software more planning, designing, creating, and debugging playbooks for phantom.

How our Splunk Phantom Admin course/training would help?

These tutorial courses will help you with the learning process of Splunk phantom admin with the SOAR platform (security orchestration, automation & response). This will make you more configure about the software system security. It solves security operations problems. Suppose, your software have limited resources, too many alerts, too many siloed products, lack of process, speed, & cost then it remediates with force multiply your team, clear 80% of alerts with no human interaction, unlock value from previous investments, establish SOPs (standard operating procedures) to be more effective, from 30 minutes to 40 seconds, & definitive ROI and hard cost savings. And it will give you work flowing ideology on security data, playbooks, actions, apps, assets, and owners.

After, getting the processed values then comes to the certification. If you get certified with the completion of training then it gives you competitive strength in automation and orchestration first, community focus, and enterprise architecture. This will make you more efficient in IT software infrastructure for ideal job opportunities with an expected high-paid salary. I wish that these statistics will give you more understanding of futuristic points of view.

Related video:

 Today, IT and businesses often find themselves in silos working separately without a shared vision of the customer experience and all the services supporting it. IT must move beyond maintaining up a time to deliver the agility and competitive edge the business needs this means better cohesion between IT and business using predictive tools to prevent service failure meet Splunk IT service intelligence.

 IT service intelligence teams can no longer afford to be reactive especially when it comes to performance and availability. A protective IT strategy is necessary to get ahead of a problem and to protect revenue and your customer experience. Splunk IT service intelligence delivers a predictive IT, running an AIs we have AI scalable data platform that can ingest, search, analyze, and all types of data. ITSI allows you to go from reactive to predictive IT while gaining insights across both IT and business services. Splunk ITSI allows customers to predict service degradation 30 to 40 minutes in advance with the proactive alert for the KPIs most at risk so you can resolve incidents before they start gaining an end-to-end view of both IT and business KPIs on a single screen so you can work on what matters most when it comes to AI ops strategy. ITSI helps you become more proactive and even predictive reduce your incident investigation time business impact outages and event noise ensure your best customer experiences yes and keep the business and IT working better together with Splunk IT service intelligence. Put AI at the heart of your operations and try the free ITSI sandbox from today.

What are the benefits of Splunk IT Service Intelligence?

From the start as we are learning the series of Splunk software tools. In this stack, we discuss that every software has its own performances, capabilities, and security management but how the software works predictive and analytic. This is the reason behind endorsing the system software like how fast service is happening, and how the software is managing by the ITs team. With this effect, there are certain benefits related to Splunk ITSI admin as:-

• Intelligent incident management: Accelerate MTTR using real-time event correlation, automated incident prioritization and integrations with IT service management (ITSM) tools.
• Advance analytics & alerting: It manages a certain function as anomaly detection, adaptive thresholding, and predictive alerts & dashboards.
• Service analyzer: Service monitoring dashboards that display dependent systems and apps. Drill- down into a service’s underlying components to determine what’s impacting its health score.
• End to End visibility: protect business performance by monitoring service health, drill down into underlying infrastructure, all from one dashboard. 

Why we should learn Splunk IT Service Intelligence?

Nowadays, in this trending world. You have met with so many tools in the IT software services. Whenever we talk about Splunk’s advanced services then intelligence plays a prominent role in the IT entities. Now, we are talking about the learning conditions for IT service intelligence. So, what are the reasons to implement a Splunk ITSI? Before we had traditional solutions and those solutions were created as operational challenges like lack of visibility, complex environment, & slow response times. The most important talk is that lack of intelligence service created a significant impact on a business like lost revenue, inefficient productivity, poor customer experiences, & struggle to innovate then it creates technical advance in the field of IT sectors on the basis of Business and IT Service Monitoring, Intelligent Incident Management, Machine Learning, and Predictive Analytics. I wish that these awareness scenarios will give you brain mapping concepts for the Splunk intelligence certified admin.

How our Splunk IT Service Intelligence course/training would help?

This tutorial will help you about understanding the core features of Splunk ITSI like IT event management, service monitoring, and advanced analytics & alerting. It will give you a balancing ideology in the field of KPIs, Data sources, entities, services, incident response, automated remediation, predictive analytics, and event analytics. Through these interactive lectures and hands-on challenges, you will be able to learn to use IT service intelligence, services & glass tables, Notable event & event aggregation policies, and deep dives-investigation with swim lane views. After this, it gives you certification and that makes you qualified for the job opportunities along with the expected high-paid salary and makes your life efficient with future scope.

Related video:  

The Challenge: DevOps as a Service for Production Stability

Most DevOps adoption stories centre on greenfield projects — shifting left, embedding CI/CD pipelines, and integrating testing early in the development lifecycle. But what happens when the immediate problem is not slow delivery, but a system that is actively breaking in production?

That was the situation Kapil faced. As DevOps Lead, his first mandate was not to build out a CI/CD practice — it was to stabilise an enterprise system experiencing recurring production blockers and environment failures. The standard DevOps playbook, designed for Agile/Kanban delivery of new features, needed to be adapted for a damage-control scenario on an existing large-scale system.

The Problem: Cascading Downtime Across Environments

The team faced a range of environment instability issues that were blocking delivery at multiple stages:

• Production blockers with downtimes ranging from 5 minutes to 1 hour
• UAT environment outages lasting 30 minutes or more
• QA downtime of up to 4 hours following deployment changes
• Infrastructure and network instability causing unpredictable failures

Adding complexity to the situation: eight separate squads — working across multiple technology stacks — were sharing a single delivery pipeline and deploying continuously. This was not a small new project. It was a large enterprise system transformation, meaning failures had wide blast radius and high business impact.

The Idea: Apply Chaos Engineering to Find and Fix Weaknesses

Chaos Engineering is the discipline of deliberately introducing controlled failures and turbulent conditions into a distributed system in order to surface hidden weaknesses before they become unplanned outages. The core insight is that complex systems will inevitably experience unexpected failures — the question is whether you discover those failure modes proactively, in a controlled experiment, or reactively, during a production incident.

In this context, Chaos Engineering was not just applied to production resiliency testing in the traditional Netflix/Simian Army sense. It was used as a structured methodology to understand and eliminate the environmental instability that was blocking the team’s ability to deliver.

Organisational Structure: Two Groups, One Goal

Effective Chaos Engineering requires clear separation of responsibilities. In this implementation, two groups operated in parallel:

• Chaos Teams (experimental group): Responsible for designing and executing controlled failure experiments — simulating server failures, severed network connections, environment crashes, and deployment-triggered outages.
• DevOps War Room team (control group): Responsible for monitoring system behaviour during experiments, capturing the impact, and coordinating remediation. Operating from a centralised “Phoenix War Room,” this team tracked real-time system state across all environments.

Establishing a steady-state baseline was the first step — defining what “normal” looked like for production, QA, and UAT environments (e.g., 24×7 availability and zero unplanned downtime as the target). Without a clear steady-state definition, it is impossible to know whether an experiment has caused a meaningful deviation.

Four Steps to Running a Chaos Engineering Experiment

The team followed a structured four-step cycle for each experiment:

1. Hypothesise the failure outcome. Before introducing any failure, the team defined what they expected to happen. For example: “If the QA environment loses its database connection during a deployment, the pipeline will fail and block all eight squads for X minutes.”
2. Design a targeted experiment. Engineers created controlled scenarios that reflected real failure patterns they had already observed — environment outages, server malfunctions, severed network connections. Experiments were scoped to avoid unnecessary blast radius.
3. Run the experiment and compare results. If the experiment revealed a weakness the team had not anticipated, it was logged as a successful chaos experiment. If the system held, the team expanded the hypothesis and tested more extreme conditions.
4. Fix weaknesses before they become system-wide failures. Discovered weaknesses were addressed immediately — before being exposed by an unplanned production event. This shifted the team from reactive firefighting to proactive hardening.

The Solution: Temporary Environments and Automatic Failure Recovery

One of the key operational changes driven by this approach was adopting a policy of ephemeral (temporary) environments for all non-production work. Rather than relying on long-lived shared QA and UAT environments — which were fragile, contested across eight squads, and difficult to recover quickly — environments were provisioned on demand and discarded after use.

This approach has several concrete benefits:

• Eliminates environment contention between squads sharing a single pipeline
• Dramatically reduces recovery time — a broken ephemeral environment is replaced, not repaired
• Forces infrastructure-as-code discipline — environments must be fully automated to be ephemeral
• Surfaces hidden dependencies that only appear when an environment is rebuilt from scratch

The broader goal was to build systems that could automatically detect and respond to component failures without human intervention — reducing the mean time to recovery (MTTR) and eliminating the long tail of environment-related blockers that had been degrading team velocity.

Key Takeaways for DevOps Teams

This case study offers several practical lessons for teams dealing with environment instability in complex, multi-squad delivery contexts:

• Chaos Engineering is not only for Netflix-scale systems. The principles apply equally to enterprise transformation programmes suffering from environment fragility.
• Define your steady state first. You cannot measure the impact of a failure experiment without a clear baseline for what healthy looks like.
• Separate experimentation from operations. A dedicated chaos team running experiments, alongside an operations team absorbing and responding to them, creates productive feedback loops without operational chaos.
• Ephemeral environments are a force multiplier. When environments are reproducible on demand, a failed environment stops being a blocker and becomes a non-event.
• Proactive failure discovery beats reactive incident response. Every weakness found in a chaos experiment is a production incident that did not happen.

For teams struggling with the gap between DevOps ideals and the messy reality of a large, unstable production system, Chaos Engineering offers a structured way to take back control — by deliberately introducing the chaos before it introduces itself.

AWS re:Invent 2019: What You Need to Know Before You Go

AWS re:Invent is consistently the largest cloud computing conference of the year. With more than 50,000 attendees at the 2018 event, re:Invent 2019 is expected to draw an even larger crowd across its multi-venue Las Vegas campus. The sheer scale of the conference—spread across six properties on and near the Strip—can overwhelm even experienced attendees. A bit of preparation, however, goes a long way toward maximising the sessions, meetings, and networking opportunities on offer.

The conference runs from Sunday, December 1 through Friday, December 6, 2019. Here is a practical breakdown of what to plan for.

Navigating the Las Vegas Strip

The main activity hubs for re:Invent 2019 are the Venetian, Aria, and MGM Grand, with additional sessions and events at the Mirage and Bellagio. Compared to 2018, the MGM Grand is carrying significantly more content this year, so factor that into your hotel choice if you have not already booked.

Getting Between Venues

AWS provides free shuttle buses between venues, but travel time between conference halls can easily reach an hour or more, especially during peak session changeovers. Once you arrive at a venue, budget additional time to navigate the hotel interiors to reach your specific room.

Other transport options include:

• Las Vegas Monorail: A faster alternative during busy periods. Note that the closest Monorail stop to the Venetian is the Linq station, leaving a short walk. The Monorail is often less crowded than shuttles during session transitions.
• Walking: Practical for shorter hops. The MGM Grand to the Aria is roughly a 20-minute walk; Aria to the Venetian is approximately 30 minutes without detours.
• Taxis and ride-sharing services: Available but can be slow due to Strip traffic during conference hours.

New Scheduling Policies to Know

AWS has updated its booking policy to help manage transit times: attendees cannot reserve sessions at different venues that are less than 60 minutes apart. Additionally, the long-standing rule applies: arrive at your session room at least 10 minutes before it starts or your reservation may be forfeited.

Venue Strategy

Mark Nunnikhoven, vice president of cloud research at Trend Micro and an AWS Community Hero, recommends a deliberate approach to managing your venue schedule throughout the week:

“Either pick one [venue] and switch around lunch time or pick a different venue every day.”

Mark Nunnikhoven, VP of Cloud Research, Trend Micro

Key destinations worth planning around include the expo hall at the Venetian, the quad at the Aria, and the various hands-on lab areas distributed across the campus.

Tip: If you are flying in, register at the airport when you land rather than at the conference halls. This can save significant time and avoid the long registration queues.

Planning Your Sessions

Re:Invent 2019 features more than 2,700 sessions, making it genuinely difficult to narrow down a personal agenda. Reserved seating fills up quickly—some sessions were already sold out ahead of the conference. Third-party tools and community-built sites have emerged specifically to help attendees filter and manage the session catalog.

AWS will again distribute topics equally across venues this year, meaning you can stay at a single venue and still cover a wide range of subject areas. Importantly, more repeat sessions are scheduled this year: if a particular talk at the Bellagio does not fit your schedule, there is a reasonable chance it will be repeated at a more convenient venue and time.

Session Formats

Understanding the different session types helps you build a balanced schedule:

• Breakout Sessions: Held in larger rooms, covering a range of expertise levels. Ideal for learning about new AWS services or getting a deep dive on ones you already use. Customer-led talks from organisations such as Netflix and T-Mobile typically appear in this format.
• Workshops (Hands-On Labs): Practical, lab-based sessions where attendees work directly with a service. These typically run around two hours—the longest format at the conference.
• Chalk Talks: Smaller, discussion-driven sessions led by AWS solutions architects. These follow a short presentation with a real-world example, then open into a group conversation. Good for interactive problem-solving.
• Builder Sessions: Led by an AWS expert, with attendance capped at around six people. Participants work in a sandbox environment to explore new or existing technologies. Highly valuable if you can secure a spot.

If you arrive at re:Invent without a full session lineup, look for the digital session boards posted around the venues. AWS staff nearby can review your interests and help you identify available options on the spot.

Keynotes

The keynotes are the headline events of the conference. Based on the pattern from recent years:

• Andy Jassy (AWS CEO) typically leads the main product announcement keynote, covering new services and major platform updates.
• Werner Vogels (Amazon CTO) follows the next day with a broader industry and technology perspective.
• Monday Night Live, hosted by Peter DeSantis (VP of AWS Global Infrastructure), is an in-depth technical session offering a rare look at the infrastructure layer powering AWS. It tends to be light on product announcements but is highly regarded by engineers who want to understand the underlying platform.

Keynote lines form well before doors open. If the ambiance is not your preference—or if your schedule is tight—all keynotes and most breakout sessions are posted online within a short window after the conference ends.

Social Activities and Networking

Re:Invent 2019 includes a full schedule of social events alongside the technical programming:

• Midnight Madness (Sunday evening): The traditional conference kickoff event, featuring music, games, and food.
• Annual Pub Crawl (Wednesday): A popular community social event connecting attendees across venues.
• DeepRacer Competitions: Autonomous model-car racing events for those interested in machine learning and AI.
• re:Play (Thursday night): A large-scale EDM concert and interactive entertainment event—one of the most-attended social events at the conference.
• Lower-key options: New this year are arts and crafts sessions, movie nights, and board games for attendees who prefer a quieter social setting.

Throughout the day, themed networking lounges are open across the campus, organised around topics such as databases, financial services, and artificial intelligence. These are worth visiting even briefly—the mix of attendees at re:Invent has broadened considerably beyond its developer-centric roots.

“There is this wide and diverse audience. You get these different perspectives, which tend to spur much better conversations.”

Mark Nunnikhoven, VP of Cloud Research, Trend Micro

Whether you are a developer, architect, or business decision-maker, the diversity of the re:Invent crowd makes the hallway track—informal conversations between sessions—as valuable as the formal agenda.

Quick Reference Checklist

• Book your hotel with venue proximity in mind—MGM Grand has significantly more content in 2019
• Reserve sessions early; popular ones fill up fast and some are already sold out
• Do not schedule sessions at different venues less than 60 minutes apart
• Arrive at session rooms at least 10 minutes before start time
• Register at the airport on arrival to avoid conference-hall queues
• Use the Las Vegas Monorail as a shuttle alternative during peak periods
• Plan your venue strategy by day or half-day to reduce cross-campus travel
• Mix session formats—include at least one workshop or builder session for hands-on learning
• Budget time for networking lounges and community social events

What Makes Software High Quality?

Software quality is often described across three dimensions, sometimes called the software quality triangle:

• Operation: How well the software functions day-to-day. This covers correctness (does it do what it claims?), usability, integrity, and reliability.
• Transition: How easily the software moves between platforms, environments, or systems. Key attributes include portability and interoperability — the ability of the software to work alongside other programs and APIs.
• Revision: How maintainable, testable, and modular the codebase is. This dimension becomes especially critical when scaling, because poor revision characteristics slow every team that touches the code.

With those dimensions in mind, here are seven actionable tips for preserving software quality as your DevOps practice grows.

1. Keep Things Simple

Complexity is the enemy of quality at scale. Simple code is easier to review, easier to test, and easier to hand off to new team members. Strive for clean interfaces, clear naming conventions, and short, single-purpose functions.

Automation is a powerful lever here. Static analysis tools and linters can automatically flag unnecessary duplication, overly long methods, and high cyclomatic complexity before code ever reaches a reviewer. Integrating these checks into your CI pipeline means quality gates run on every commit, not just at release time.

When evaluating new tooling, also ask whether it reduces cognitive load for developers or adds to it. The best DevOps toolchain is the one your team will actually use consistently.

2. Make Data-Driven Decisions

Gut feeling has a poor track record when it comes to prioritizing quality improvements. Instrument your software to collect meaningful metrics: error rates, latency percentiles, deployment frequency, mean time to recovery (MTTR), and user behavior signals such as feature adoption or drop-off points.

For example, usage analytics can reveal which features drive the most user engagement, so your team can invest disproportionately in stabilizing and improving those paths. Conversely, low-traffic areas may be candidates for deprecation rather than maintenance overhead.

Observability tooling — distributed tracing, structured logging, and real-time dashboards — makes this data actionable in production, not just in retrospectives.

3. Build for Users, Not Just for Checklists

DevOps frameworks and compliance checklists exist for good reason, but they are a floor, not a ceiling. It is easy for teams under delivery pressure to tick boxes while shipping software that nobody actually wants to use.

User-centric development means involving real users early — through usability testing, beta programs, and feedback loops — and treating their experience as a first-class quality metric. A feature is not done when it passes automated tests; it is done when it demonstrably helps users accomplish their goals.

Embedding product thinking into DevOps teams (sometimes called DevOps + Product) helps ensure that velocity is directed toward outcomes, not just outputs.

4. Meet Established Code Quality Standards

Industry standards provide a useful external reference point for code quality, especially when scaling into new markets or regulated industries. The Consortium for IT Software Quality (CISQ) publishes automated quality characteristic measures based on the ISO 25010 standard, covering reliability, security, performance efficiency, and maintainability.

Practically, this means paying attention to patterns that degrade quality at the code level: unsafe buffer handling, unbounded loop computations, poor exception management, and tightly coupled architecture. Code review checklists, architecture decision records (ADRs), and regular dependency audits all help teams stay aligned with these standards without relying on manual heroics.

5. Practice Continuous Testing

Testing should not be a phase that happens before release — it should be a continuous activity woven into every stage of the delivery pipeline. This means:

• Unit and integration tests run on every commit.
• Performance tests run against staging environments to catch regressions before they reach production.
• Security scanning (SAST, DAST, dependency vulnerability checks) is automated in the pipeline.
• Penetration testing is scheduled regularly, not just annually, especially after significant architectural changes.
• API contract tests prevent breaking changes from propagating across services in a microservices architecture.

The goal is a fast feedback loop: developers should know within minutes, not days, whether a change has broken something. Slow feedback is one of the most common reasons quality degrades at scale.

6. Follow Up on Assessments and Audits

Assessments — whether they are security audits, architecture reviews, or retrospectives — produce recommendations. Those recommendations have zero value unless someone owns them and drives them to completion.

Build follow-up into your process explicitly. Track audit findings as backlog items with owners and due dates. Use blameless post-mortems to generate improvement actions, and review whether those actions actually moved the needle in the next retrospective. Some useful self-assessment questions to ask regularly:

• Is our automation reducing toil, or has it introduced its own complexity?
• Did the changes we made after the last review produce the outcomes we expected?
• Are there manual steps in our pipeline that are still candidates for automation?
• Are our quality metrics trending in the right direction over the past quarter?

7. Prioritize Reliability and Efficiency

Scaling something unreliable just delivers failures faster. Reliability engineering — defining SLOs (Service Level Objectives), tracking error budgets, and designing for graceful degradation — must be a first-class concern before you scale, not after.

Efficiency matters too, both in the software itself (response time, resource consumption) and in the delivery process (lead time, deployment frequency). Inefficient infrastructure or bloated pipelines add cost without adding value. Regularly profile both your runtime performance and your CI/CD pipeline performance to find and eliminate waste.

Together, reliability and efficiency define whether scaling DevOps creates real business value or simply increases the blast radius of existing problems.

Bringing It Together

Every tip above serves a single underlying principle: software quality is not a property you bolt on at the end of a sprint — it is a discipline you maintain continuously as your team, codebase, and infrastructure grow. The teams that scale DevOps successfully are those that treat quality as a shared responsibility, automate quality gates early, and measure outcomes rather than just activity.

Start with the areas where your current process is weakest — whether that is test coverage, observability, or follow-through on audit findings — and build from there. Incremental, measurable improvement is far more sustainable than a big-bang quality initiative.

Data Theorem, Inc. a provider of modern application security, introduced a new SPA security service that delivers automated discovery and continuous dynamic runtime vulnerability inspection of modern web single-page applications (SPAs). Purpose-built for SPAs, the new service is differentiated in its runtime security analysis that supports both GraphQL and REST API services, the popular services for SPAs that dynamically deliver a faster and richer web user experience.

With DevOps teams rapidly building web SPAs, security and IT teams using traditional web app scanners lack the ability to gather application insights and inspect for security vulnerabilities on these new modern web apps. Now with this new offering from Data Theorem, for the first time users can fully discover and inspect vulnerabilities with dynamic runtime analysis for both GraphQL and REST API services.

Tech News: Dremio Releases Data Lake Engines for AWS, Azure, and Hybrid Cloud; Enhances Performance on Data Lake Storage

“SPA security is the new frontier for modern web application security, and like mobile it is tightly coupled to the explosion and growth of GraphQL and API backend services,” said Doug Cahill, senior analyst and group practice director of cybersecurity for ESG. “To best protect these services from attack, organizations need a solution that delivers both continuous security vulnerability inspection and runtime analysis that supports both GraphQL and REST API services.”

Businesses today delivering modern web applications build SPAs to deliver a richer and faster user experience that is similar to what they deliver with their mobile apps. Similar to mobile app protection, traditional web app scanners lack the ability to add security insights to SPAs because of the dynamic nature of the SPA JavaScript architecture. In addition, GraphQL adds a new attack surface due to the enhanced flexibility it provides, making it difficult to protect against malicious queries. These attack queries could lead to denial of service attacks, or unauthorized access to private data.

“Growth of SPA deployment and usage increases every year because organizations want their web experience to be as good as their mobile app experience,” said Doug Dooley, Data Theorem COO. “But security tools have not kept up with this modern software development trend. With our first web app security offering launching today, Data Theorem is leaping ahead of the competitive landscape to now serve users’ complex security needs beyond API and mobile. We were already leading in runtime analysis for mobile apps, and now we offer similar depth of runtime analysis to protect these popular SPAs.”

Tech News: Oracle Expands its Security Portfolio with New Cloud Services; Unveils New Innovations for its Data Management Portfolio

Today’s SPA security solution is offered as a component of Data Theorem’s API Discover and API Inspect, which together address security concerns such as Shadow APIs, Serverless Applications, and API Gateway cross-check validation by conducting continuous security assessments on API authentication, authorization, encryption, availability, serverless functions, and policy compliance.

The API security solutions support Amazon Web Services, Google Cloud, and Microsoft Azure to discover modern APIs and to enumerate the specification using standards such as Swagger and Open API 3.0.

The Culture vs. Technology Debate Has Run Its Course

When DevOps first emerged as a concept, many engineers assumed it was a passing trend — another buzzword destined to fade as quickly as it arrived. More than a decade of sustained industry conversation has proven that assumption wrong. DevOps is not a fashion; it is a structural shift in how software is built, tested, released, and maintained.

Yet widespread adoption remains uneven. Organisations like Google, Amazon, Facebook, and Netflix are routinely cited as high-performing examples. Many others continue to struggle. The barriers range from team size and organisational politics to budget constraints and deeply entrenched ways of working. But one underappreciated obstacle is conceptual: the persistent belief that DevOps is, at its core, a culture.

Calling DevOps a culture is not wrong. But it is incomplete — and that incompleteness has real consequences for how teams try to adopt it.

Why Reducing DevOps to Culture Causes Problems

When organisations focus exclusively on culture, they tend to undervalue the tools, automation pipelines, and technical practices that make DevOps work in practice. Continuous integration, continuous delivery, infrastructure as code, observability — these are not nice-to-haves layered on top of a cultural shift. They are the mechanisms through which cultural change becomes observable and measurable.

The opposite failure mode is equally common. Teams that focus only on tooling — standing up a CI/CD pipeline without addressing communication norms or shared ownership — find that the technology alone does not produce the outcomes they expected.

The result is a fruitless binary: DevOps is a culture versus DevOps is a technology. Neither camp is fully right, and debating the framing consumes energy that could be spent on actual improvement.

What the Facebook Analogy Reveals

A useful way to think about this is to look at the history of social networks. Facebook and Twitter fundamentally changed how people communicate globally. MySpace, despite being an earlier entrant in the same space, did not achieve the same lasting impact.

The reason is not purely technological and not purely cultural. Facebook succeeded because the product was designed in a way that aligned with how people naturally want to connect and share. The technology was inseparable from the behaviour it enabled. Neither the platform nor the social habits it created can be understood in isolation.

DevOps works the same way. Culture and tooling are not competing explanations — they are co-dependent forces. The question is not which one matters more. The question is how to structure their interaction so that adoption is practical, measurable, and sustainable.

DevOps Adoption Is Growing — But Slowly

The annual State of DevOps Reports, produced by Puppet in partnership with the DevOps Research and Assessment (DORA) team, tracked self-reported DevOps team membership over several years. According to the 2017 edition of that report, the figures looked like this:

• 2014: 16% of respondents identified as working in a DevOps team.
• 2015: 19% of respondents identified as working in a DevOps team.
• 2016: 22% of respondents identified as working in a DevOps team.
• 2017: 27% of respondents identified as working in a DevOps team.

Importantly, the same report noted that 90% of those DevOps teams were operating within medium- or high-performing IT organisations. Despite the well-documented risk of DevOps silos — where a dedicated DevOps team inadvertently becomes another handoff boundary — the data suggests that structured DevOps adoption correlates strongly with better overall IT performance.

Growth from 16% to 27% over three years is meaningful, but it also reveals how much room for improvement remains. The culture framing, on its own, has not been sufficient to accelerate that pace.

The Case for a Standards-Based Approach

A more productive frame for DevOps is to treat it as a transformation process and a collaboration philosophy — one that benefits from concrete, shared standards rather than aspirational cultural statements.

Standards serve several functions that culture alone cannot:

• They are technology-agnostic. A well-written standard applies regardless of whether your stack runs on Kubernetes or bare metal, whether your team uses GitHub Actions or Jenkins.
• They are team-size-independent. A five-person startup and a five-hundred-person enterprise can both work toward the same deployment frequency or change failure rate targets.
• They create shared language. Standards give developers, operations engineers, security teams, and business stakeholders a common vocabulary for evaluating progress.
• They support iteration. Standards can be adopted incrementally, refined based on feedback, and updated as the industry evolves — much like software itself.

Rather than framing DevOps adoption as an all-or-nothing cultural transformation, organisations can decompose it into specific, measurable objectives. This reduces the risk of paralysis in conservative environments and gives teams something concrete to work toward.

Existing Standards Worth Studying

Several established frameworks already demonstrate what standards-based thinking looks like in practice:

• The Twelve-Factor App methodology provides a set of principles for building software-as-a-service applications that are portable, scalable, and operationally sound. Its twelve factors — covering configuration management, dependency isolation, logging, and more — are concrete enough to audit and adopt incrementally.
• Cloud Native principles, as promoted by the Cloud Native Computing Foundation (CNCF), define how applications should be architected to take advantage of modern infrastructure. These include containerisation, dynamic orchestration, and microservices design.
• Consortium for IT Software Quality (CISQ) standards provide automated measures of software quality based on structural characteristics such as reliability, security, performance efficiency, and maintainability.

None of these frameworks requires an organisation to first achieve a particular culture before they become applicable. They offer entry points that teams can use from wherever they are today.

Start Where Your Teams Are

The most effective DevOps adoption paths are not the ones that most closely match a textbook definition. They are the ones that begin with an honest assessment of current practices and introduce targeted improvements in manageable increments.

This means resisting the temptation to impose a single model wholesale. It means identifying the friction points between developers and operations — handoff delays, environment inconsistencies, manual deployment steps — and addressing them with specific, standard practices rather than broad cultural mandates.

Standards create the conditions in which cultural change becomes possible. When teams share tools, processes, and expectations, collaborative habits tend to follow. The culture does not have to come first; in many cases, it emerges as a consequence of working within well-designed systems.

Key Takeaways

• DevOps is neither purely a culture nor purely a technology — both are necessary, but neither is sufficient on its own.
• The culture-first framing can lead to vague aspirations that are difficult to measure or act on, particularly in large or conservative organisations.
• A standards-based approach gives teams concrete, technology-agnostic goals that can be adopted incrementally and refined over time.
• Existing frameworks such as the Twelve-Factor App, Cloud Native principles, and CISQ standards offer practical starting points.
• Successful adoption begins from where your teams are today — not from where a definition says they should be.

Why Secure Cloud Migration Still Matters

Cloud adoption has become the default infrastructure strategy for most organizations, spanning both the public and private sectors. With that growth comes an expanding attack surface, increasing regulatory scrutiny, and the practical challenge of moving sensitive data out of on-premises environments without introducing new risk.

The scale of adoption also means that cloud security is no longer a niche concern. Hybrid cloud platforms are now mainstream, IoT is generating massive data volumes that flow through cloud pipelines, and shadow IT means that data is frequently moving to cloud services without formal oversight. Against that backdrop, a structured approach to secure cloud migration is essential, not optional.

The seven recommendations below address the full lifecycle of a migration: what you need to understand before you move data, how to structure access and encryption, and how to verify that controls are actually working once data is in the cloud.

Before You Migrate: Four Foundational Steps

The first four tips focus on your current data environment. Skipping this preparation phase is one of the most common and costly mistakes in cloud migrations.

1. Know Your Data

Before a single byte moves to a cloud provider, you need a clear inventory of what data you actually hold and where it lives. Think of it like decluttering and cataloguing before putting belongings into storage — moving unexamined data into the cloud does not make it safer or more organized; it just makes the problem harder to see.

• Identify where sensitive data currently resides across all systems, including end-user devices and departmental servers.
• Audit shadow IT: many teams are already using cloud services — SaaS tools, file-sharing platforms, collaboration apps — without formal approval or visibility.
• Classify data by sensitivity. At minimum, distinguish between public, internal, confidential, and regulated data categories (for example, data subject to HIPAA, PCI-DSS, or GDPR).
• Document existing protections so you have a baseline to replicate or improve in the cloud environment.

Numerous vendors offer data discovery and classification tooling that can accelerate this process at scale.

2. Define and Enforce a Data Lifecycle Policy

A data lifecycle policy answers the fundamental question: what happens to data from the moment it is created to the moment it is destroyed? Without this policy in place before migration, you will replicate your existing data governance gaps into the cloud.

• Document what data is collected, where it flows, how long it is retained, and when it should be deleted.
• Assign clear ownership and accountability for each data category — not just on paper, but in practice.
• Verify that staff training is current and that employees understand the policy as it applies to cloud services.
• Establish governance mechanisms — ideally automated policy enforcement — that govern how data moves between on-premises and cloud environments.

3. Understand Your Cloud Deployment Options

Choosing the right cloud model for your data is an architectural decision, not just a procurement one. The four primary deployment models each carry different security and compliance implications.

A common mistake is conflating the terms private cloud and private sector. A private cloud is defined by dedicated resource pooling for a single organization — it is independent of whether the owning organization is public or private sector. Align your architecture team on these definitions before vendor discussions begin.

4. Map Identity and Access Management (IAM) Before You Move

In cloud environments, the customer — not the cloud provider — is responsible for defining who can access what within their tenancy. This is a fundamental aspect of the shared responsibility model, and it catches many organizations off guard.

• Document data owners, data custodians, and all roles that have read, write, modify, or delete permissions for each sensitive dataset.
• Design IAM policies around the principle of least privilege: grant only the permissions required for a given role, and no more.
• Build role-based access control (RBAC) structures that can be audited and updated efficiently as staff join or leave.
• Establish processes for privileged access management (PAM) for system administrators, including background checks and segregation of duties as required by your compliance framework.
• Understand that compliance requirements — PCI-DSS, HIPAA, FedRAMP, SOC 2, and others — will shape your cloud architecture. Map those requirements to IAM policies before finalizing your design.

After Migration: Three Controls to Enforce and Verify

5. Apply End-to-End Encryption

Encryption is non-negotiable for sensitive data in the cloud — but it is frequently misconfigured or partially implemented. A meaningful proportion of cloud databases are deployed without encryption enabled, representing a significant and avoidable exposure.

• Data at rest: Ensure that storage volumes, databases, and object stores are encrypted using strong, current algorithms (AES-256 is standard). Confirm this is enforced by policy, not just available as an option.
• Data in transit: Enforce TLS for all data moving between services, between environments, and between users and cloud endpoints. Disable deprecated protocol versions.
• Key management: Determine who controls the encryption keys. Customer-managed keys (CMK) give you control but require operational discipline. Provider-managed keys are operationally simpler but reduce your independence. Consider whether a dedicated key management service (KMS) or hardware security module (HSM) is appropriate for your risk profile.
• Scope: Decide whether you will encrypt all data or only classified/sensitive data, and document that decision with a rationale your auditors can review.

6. Test Your Controls Continuously

Moving data to the cloud and assuming it is secure is not a security posture — it is wishful thinking. Controls must be verified regularly, and cloud environments change frequently enough that annual assessments are insufficient.

• Require your cloud provider to demonstrate support for vulnerability scanning and penetration testing within their environment. Most major providers have documented processes for authorizing customer-initiated testing.
• Run vulnerability assessments on a scheduled and on-demand basis, with frequency calibrated to the sensitivity of the workload.
• Implement cloud security posture management (CSPM) tooling to continuously monitor for misconfiguration — exposed storage buckets, overly permissive security groups, disabled logging, and similar issues.
• Establish an incident response plan specific to your cloud environment, and test it. Tabletop exercises that simulate a cloud-specific breach scenario (e.g., compromised service account credentials, a misconfigured S3 bucket exposing sensitive data) are valuable and underutilized.
• Ensure you have sufficient visibility into your cloud environment: logging, monitoring, and alerting should be configured so that anomalous access or data movement is detectable in near real time.

7. Back Up Data in a Distinct Fault Domain

Availability is part of security. Data that cannot be recovered after an incident — whether a ransomware attack, accidental deletion, or provider outage — is effectively lost.

“To spread risk most effectively, back up all data in a fault domain distinct from where it resides in production. Some cloud providers offer backup capabilities as an extra cost option, but it isn’t a substitute for proper backups. Customers, not cloud providers, are responsible for determining appropriate replication strategies, as well as maintaining backups.”

Gartner

• Store backups in a geographically separate region or with a different provider than your production environment. A failure or attack affecting one region should not affect your backups.
• Test restores regularly. A backup that has never been restored is an untested assumption, not a verified control.
• Understand your provider’s native backup capabilities and their limitations. Managed database snapshots, for example, may not protect against application-level corruption or accidental bulk deletion.
• Align backup retention schedules with your regulatory obligations and recovery time objectives (RTO) and recovery point objectives (RPO).

Additional Considerations

These seven tips address the core security controls for a cloud data migration, but they are not exhaustive. A complete cloud security program also requires attention to:

• Contract terms: Understand what your cloud provider is and is not liable for. The shared responsibility model varies by service type (IaaS, PaaS, SaaS) and by provider.
• Cost management: Wasted cloud spend on non-production resources is a real and well-documented problem. Tagging strategies, budget alerts, and regular rightsizing reviews help ensure that resources — and the security controls applied to them — remain intentional rather than accidental.
• Vendor lock-in: Evaluate your ability to exit a provider or move workloads. Portability considerations influence both architecture decisions and your negotiating position on contract terms.
• Ongoing governance: Cloud environments are dynamic. A migration is not a one-time event; governance processes must be continuous and adaptable as new services, new data types, and new threats emerge.

Organizations that moved sensitive data to the cloud years ago cannot assume that past decisions remain appropriate for new workloads or new business areas. Each new migration deserves the same structured evaluation outlined above.

Summary

1. Know your data — inventory and classify before you migrate.
2. Define a data lifecycle policy — govern data from creation to deletion.
3. Choose the right cloud model — private, public, community, or hybrid, based on your requirements.
4. Map IAM roles and responsibilities — you own access control in your cloud tenancy.
5. Encrypt end to end — at rest, in transit, and with clear key management ownership.
6. Test controls continuously — vulnerability scanning, penetration testing, and posture management.
7. Back up to a distinct fault domain — and verify restores work.

Cloud migration security is a discipline that requires upfront preparation, rigorous implementation, and continuous verification. These seven steps provide a practical framework for technology and security leaders navigating that journey.

Cloud Computing as a Category-Defining Disruption

Few technologies have reshaped enterprise IT as fundamentally as cloud computing. What began as a convenient way to offload infrastructure costs has evolved into the primary delivery model for software, platforms, and computing resources across every industry vertical. The scale of adoption, the pace of innovation, and the economic pressure on legacy vendors all point to the same conclusion: cloud computing is not just another IT trend — it is a structural shift in how organisations build and consume technology.

Market Scale and Growth Trajectory

According to a Bain & Company research report titled The Changing Faces of the Cloud, the global cloud IT market was projected to grow from approximately $180 billion to $390 billion by 2020, representing a compound annual growth rate (CAGR) of roughly 17%. The same report noted that cloud demand accounted for 70% of related IT market growth as far back as 2015 — a signal that cloud was already the dominant engine of IT spend, not a niche supplement to it.

Enterprise adoption at the top of the market reinforced this trajectory. At the time of writing, 48 of the Fortune Global 50 companies had announced plans to adopt cloud services across a range of IT applications. When the world’s largest organisations commit to a technology at that scale, the downstream effect on vendors, tooling, skills demand, and best practices is enormous.

“Cloud computing represents the biggest IT industry disruption in several years. CIOs will need to put their heads together in order to aid their company successfully and safely navigate the cloud journey.”

Shashank Dixit, CEO, Deskera

Why Enterprises Are Moving to the Cloud

The migration from on-premises infrastructure to cloud-based systems is driven by several converging forces:

• Cost efficiency: Cloud removes large upfront capital expenditure on hardware and replaces it with predictable, consumption-based operational spend. Over time, this model allows organisations to scale costs in line with actual demand rather than peak projections.
• Connectivity and integration: Cloud-native applications are designed to interoperate. APIs, managed services, and platform ecosystems make it easier to connect disparate systems than legacy on-premises stacks typically allow.
• Access to emerging technology: Cloud providers continuously add capabilities — machine learning inference, managed databases, serverless compute, edge services — that would take years and significant investment to build in-house. Organisations can adopt these capabilities with relatively low friction.
• Reliability and managed operations: Hyperscale cloud providers invest heavily in redundancy, global infrastructure, and managed SLAs. For many workloads, this exceeds what an enterprise data centre can cost-effectively achieve independently.
• Digital transformation pressure: Competitive dynamics push organisations to move faster. Cloud reduces the infrastructure provisioning cycle from weeks to minutes, compressing the time from idea to production deployment.

Segment-Level Dynamics: SaaS, PaaS, and IaaS

Not all cloud segments grow at the same rate or face the same competitive dynamics. Gartner’s research director Sid Nag described the overall public cloud market as maturing, with growth rates expected to moderate slightly from around 17% in 2016 toward 15% by 2020. However, specific segments remained strong growth drivers:

• Financial SaaS applications were singled out as a segment with sustained strong growth, reflecting the pressure on financial services firms to modernise core systems without the cost and risk of large custom builds.
• PaaS (Platform as a Service) user markets were also expected to see robust expansion as developers sought higher-level abstractions for building and deploying applications.
• IaaS (Infrastructure as a Service) was projected to deliver increasing value per dollar spent — more compute performance, memory, and storage at equivalent price points — alongside growing automation in IT outsourcing delivery. This effectively rewards organisations that increase their IaaS footprint over time.

“As buyers intensify and increase IaaS activity, they will be getting more for their investment: ongoing enhancement of performance, more memory, more storage for the same money, and increased automation in traditional IT outsourcing delivery.”

Sid Nag, Research Director, Gartner

The Rise of Cloud-Native Application Development

One of the more telling indicators of cloud’s disruptive reach is the emergence of applications designed exclusively for cloud delivery. Rather than adapting existing on-premises software to run in cloud environments — a compromise approach sometimes called “lift and shift” — a growing number of vendors and internal engineering teams are building with cloud primitives from the ground up. This means leveraging managed services, auto-scaling, distributed data stores, and continuous delivery pipelines as first-class design decisions rather than afterthoughts.

Cloud-native development shortens release cycles, reduces operational overhead, and produces systems that are inherently more elastic and resilient than their monolithic predecessors. For organisations competing on software delivery speed, this architectural shift is not optional — it is a prerequisite for keeping pace.

Connectivity and Reach as Accelerants

Cloud adoption does not happen in isolation. The expansion of internet connectivity — through mobile broadband including 3G and 4G networks — extends the effective reach of cloud services to users and devices that were previously constrained by network access. As more of the global population and the device ecosystem gains reliable connectivity, the addressable market for cloud-based services expands in turn.

This creates a reinforcing cycle: broader connectivity increases cloud adoption, cloud investment funds further infrastructure and service development, and improved services attract more users and workloads. For DevOps teams, this means the operational and architectural decisions made today will need to accommodate an increasingly distributed, globally connected user base.

What This Means for DevOps and Engineering Teams

Cloud’s disruptive character is not limited to the boardroom or the procurement function. It reshapes how engineering teams work day to day:

• Infrastructure as code becomes a standard practice rather than an advanced technique, since cloud APIs make programmatic infrastructure management practical at any scale.
• Observability and cost management emerge as first-class engineering responsibilities. When compute and storage are metered by consumption, engineering decisions directly affect the cost line.
• Skillsets shift from hardware administration and data centre operations toward cloud-native tooling, containerisation, orchestration, and distributed systems design.
• Security models evolve from perimeter-based approaches to identity-centric, zero-trust architectures appropriate for workloads running outside organisational boundaries.
• Vendor ecosystems expand, requiring teams to evaluate managed services against self-managed alternatives and make deliberate build-versus-buy decisions at the infrastructure layer.

Conclusion

Cloud computing’s disruptive impact on IT is not a future prediction — it is an observable reality reflected in market data, enterprise adoption patterns, and the daily work of engineering teams. The economic model, the pace of innovation at hyperscale providers, and the pressure on organisations to compete digitally all sustain cloud’s central role in IT strategy. For DevOps practitioners, understanding and working effectively within cloud environments is not an optional specialisation: it is foundational to modern software delivery.

Cloud Computing’s Startup Boom

By 2017, cloud adoption had moved from a niche IT strategy to a mainstream business imperative. Nearly every enterprise — from mid-market companies to global corporations — was either beginning its cloud journey or accelerating it. That demand created fertile ground for a new generation of startups, each competing to solve a specific pain point: hybrid data management, cloud security, desktop delivery, hyper-scale storage, or simplified public cloud operations.

What separated the most promising players from the crowd was not simply product novelty, but the ability to deliver disproportionate value in a well-defined niche. Below are ten cloud startups that were drawing attention in 2017 for doing exactly that.

The 10 Cloud Startups to Watch in 2017

1. Apcera

Founded: 2012 | CEO: Derek Collison

Apcera built a container management platform aimed at enterprises operating across cloud environments. Its distinguishing feature was support for both legacy applications and modern cloud-native workloads — a significant advantage for organizations mid-migration. The platform bundled scheduling, orchestration, networking, and storage management into a unified offering, reducing the operational complexity of hybrid deployments.

2. Cazena

Founded: 2015 | Founder: Prat Moghe

Cazena positioned itself in the big data space, offering a Data Platform-as-a-Service (dPaaS) that automated data movement to and within cloud environments. It was designed specifically for Azure and AWS deployments, helping data teams run analytics workloads in the cloud while also handling data migration governance, security controls, and compliance requirements — all through a managed service model.

3. Dizzion

CEO: Steve Prather

Dizzion targeted small and medium-sized businesses with desktop-as-a-service (DaaS) solutions. Beyond virtual desktops, its portfolio included endpoint management, application delivery, and cloud storage. The company carved out a particular foothold in regulated, remote-workforce industries such as healthcare and finance, where secure, centrally managed desktops reduce both compliance risk and IT overhead.

4. Elastifile

Founded: 2013 | Founder: Amir Aharoni

Elastifile tackled one of the harder problems in hybrid cloud: unified data management across geographically distributed and architecturally disparate storage systems. Its core product, the Elastifile Cloud File System, was a distributed flash storage solution that presented data from multiple locations as a single, locally accessible file system. This approach simplified data access patterns for applications that span on-premises and cloud infrastructure.

5. Hedvig

Founded: 2012 | Founder: Avinash Lakshman

Hedvig specialized in hyper-scale storage, building its Distributed Storage Platform to replicate and protect data across private and public cloud environments simultaneously. The focus on multi-environment data protection made it attractive to enterprises that needed high availability and disaster recovery without being locked into a single cloud vendor’s storage model.

6. Infinite Ops

Founded: 2015

Infinite Ops aimed to reduce the operational complexity of running workloads in the public cloud. It bundled key IT management capabilities — including workspace management, databases, identity management, and firewall configuration — into a single software package. The goal was to give IT teams a simpler, more consolidated way to deploy and govern cloud resources without stitching together multiple separate tools.

7. Netskope

Founded: 2012 | CEO: Sanjay Beri | Headquarters: Los Altos, CA

Netskope operated in the cloud security space, providing enterprises with deep visibility into cloud workloads and the applications their employees use. Its platform was designed to identify threats, enforce security policy, and reduce the risk of data loss across cloud services. By 2017, cloud-access security brokers (CASBs) were an emerging category, and Netskope was one of the recognized leaders in that segment.

8. Pulseway

Founded: 2011 | CEO & Founder: Marius Mihalec | Parent: MMSOFT Design

Pulseway differentiated itself with a mobile-first approach to IT management. Built for managed service providers (MSPs) and IT administrators, it enabled remote monitoring and management of cloud and on-premises infrastructure from smartphones, tablets, or desktop browsers. Endpoint protection was also part of the core offering. The emphasis on accessibility from any device made it particularly relevant for lean IT teams managing distributed infrastructure.

9. Sapho

Founded: 2014 | CEO & Founder: Fouad ElNaggar

Sapho took a different approach to enterprise productivity, building a platform that allowed organizations to create lightweight micro-apps on top of their existing enterprise systems — ERP, CRM, HRIS, and others. Rather than replacing back-end systems, Sapho surfaced the specific data and actions employees needed most, making those accessible remotely from any device. The result was reduced context switching and faster task completion without requiring a full system overhaul.

10. Skyhigh Networks

Founded: 2011 | CEO: Rajiv Gupta

Skyhigh Networks provided enterprises with real-time visibility into their cloud service usage — a capability often described as cloud access security brokering. Its platform allowed security and IT teams to detect threats, monitor cloud deployments, enforce usage policies, and track the overall health of cloud initiatives. A broad set of third-party integrations expanded its usefulness across existing security toolchains.

What These Startups Had in Common

Looking across these ten companies, a clear pattern emerges: each identified a narrow, well-defined problem within the broader cloud ecosystem and built a focused solution around it. None tried to be a general-purpose cloud provider competing with AWS or Azure. Instead, they targeted the gaps those platforms left open — data governance, endpoint security, distributed storage, desktop delivery, and operational simplicity.

Most were founded within the five years preceding 2017, yet had already built meaningful customer bases in their respective niches. For DevOps and infrastructure teams evaluating tooling in 2017, these companies represented a new class of specialist vendors worth including in any cloud strategy evaluation.

A Note on Current Status

This article reflects the cloud startup landscape as it stood in mid-2017. Several of these companies have since undergone significant changes. Readers researching any of these vendors should verify their current status, product offerings, and ownership before making procurement or architectural decisions.

New data from almost a thousand global respondents has found there are substantial benefits to be had from cloud-based tools for DevOps.

CA Technologies released the first-of-its-kind study in a move the company says quantifies the benefits for companies the combine DevOps methodologies with cloud-based tools and delivery mechanisms.

Revealed at the company’s first annual ‘Built to Change Summit’, CA Technologies asserts the intelligence supports the announcement of innovations across its portfolio.

The study was conducted by Freedom Dynamics in early 2017 and made direct comparisons between traditional software development and delivery methods, the use of DevOps and cloud separately, and also with the extensive use of both together.

The study indicated that companies practicing DevOps with cloud-based tools and delivery resulted in:

• 81% improvement in overall software delivery performance (over an improvement of just 52% when practicing DevOps alone or 53% when leveraging cloud without DevOps)
• Almost 2x faster software delivery speed
• 80% better predictability of software performance
• 66% improvement in software quality for fewer defects
• 69% improvement in customer experience than baseline of traditional software development and delivery models
• More than 2x better cost control for the tools and services that DevOps teams actually use

According to the company, the results speak for themselves in laying out definitive advantages of software delivery performance for any enterprise in terms of cost, quality and efficiency.

CA Technologies president and chief product officer, Ayman Sayed says being built to succeed in today’s world means being built to change.

“Working around the world with customers of all sizes, this change manifests in the move to public cloud workloads for greater flexibility, agility and cost efficiency. Our job is to ensure that companies have the choice to run their workloads where and how it makes sense,” says Sayed.

“We provide the tools, technologies and services to support this hybrid approach to internal development. Now the data proves the benefits and value of the approach.”

CA Technologies asserts that it has introduced new software to meet customer needs in any deployment and support this era of development and delivery.