devopsy.kinsta.cloud

Tag: business continuity

  • Heat Cooks Twitter DC | AI Will Kill All Humans | Patreon Layoffs, CSAM Claim

    Heat Cooks Twitter DC | AI Will Kill All Humans | Patreon Layoffs, CSAM Claim

    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: Twitter is in a “non-redundant state” thanks to a hot summer, AI is likely to eliminate us, and Patreon fires 80 staff amid nasty allegations (TW: Child safety). (more…)

  • No Matter How Things Change, Have a Plan

    No Matter How Things Change, Have a Plan

    Had enough change yet? It is almost amusing that I and some other tech people had that conversation a decade ago, and since then, nothing has slowed down. Our conclusion was that, for the near future, change would be constant. That conclusion was right; I’d have to ping everyone else to see what they think, but “near future” turned out to be longer than I expected.

    Inevitably, though, change requires taking a breather at times. It appeared that high-tech was finally ready to admit that burning out your staff was not a viable long-term business model, and was slowing down … and then, COVID-19 hit. Now I’m hearing rumblings about going back to non-stop change as if the last couple of years were a vacation and staff is all rested up and ready to replace massive chunks of the infrastructure.

    The reason that change requires intermissions, though, is not 100% about staff and burnout. That only shows up when you’re making a ton of change non-stop. Before staff burnout becomes an issue, recovery and business continuity plans become outdated. At the rate we’ve been running, I’d go so far as to say they are likely useless.

    Yes, all this change has brought us some cool stuff. While we are busier, some of the busywork is far easier, or even non-existent now—but that doesn’t change the fact that you need to breathe. This is a perfect time to go over plans to keep the business on its feet in case of IT catastrophe—or at least some major systems catastrophe. Saying “We’ll just deploy a new version” is cool, but it only works in some scenarios. I touched on this and discussed one case where it doesn’t work in October 2021. But there are a ton more. Every environment is different, but hardware failures have not disappeared and destructive writes still occur, as just two more examples. Your infosec team can give you a few more examples.

    Knowing what you’re going to do when the worst-case scenario happens is huge. And for those who’ve never been through it, knowing before people are stressed and asking you for a timeline will save you a lot of headaches.

    For those who’ve never had a DR or business continuity plan, consider it. At least have a basic DR plan that lists critical systems, things most likely to go wrong and what the steps are to recover it and get things moving again. The process of making such a list will often uncover things that should be done but aren’t—like backups or backup verifications.

    For those with a DR or business continuity plan, I’ll take a wild shot and say, “It’s out of date.” Organizations tend to create them and then forget about them. These plans should involve a bit of each project, so it’s taken care of in bite-sized chunks, but—probably because the first implementation of DR or BC is normally a massive project—it tends to be set aside and revisited every few years. Don’t do that.

    As I’ve said before, you and yours have built the heart of the modern enterprise. Don’t forget to protect it. It doesn’t take much to use some of these sweet new technology advances to put in DR procedures. Tack DR review/updates onto each major initiative, be it a new product or a big change to existing software. And keep rocking it. If you have a say in your organization, consider slowing the pace down for a bit and even updating DR. If you don’t have a say, may your employer be wise enough to do so.

  • COVID-19: Don’t Sacrifice DevOps

    COVID-19: Don’t Sacrifice DevOps

    Like everyone else, I’ve been following COVID-19/Coronavirus issues. My focus is more on the IT impact of the disease and its status as a pandemic.

    Let’s start by saying it isn’t the end of the world. Yes, it’s serious. Yes, it will be disruptive. Yes, those impacted by the worst aspects of the disease will leave a hole. But when it is over, and the tide has swept by, the vast majority of people will still be here, still trying to do what they need to do.

    That includes ITOps/DevOps maintaining whatever you put in during the rush to work remotely. Some organizations will be happy to throw something up and then rip it back down, but most will not. Once they’ve worked out how to work remotely, they’ll want to keep that as an option. Some to offer more work/life balance to employees, others to have a backup plan in case of emergency. Ask any company in Katrina’s path, remote work plans born in emergencies tend to hang around.

    It is the nature of DevOps to be nimble and reactive, planning on improving things as time goes on. That’s a good feature of both DevOps and modern IT teams. But some things are less nimble than others, and the rush to remote work is going to show that in a hard way.

    The VPN chosen or expanded to enable remote workers is not likely to be swapped out easily or quickly. While there is a sense of urgency—if you follow /r/sysadmin or to a lesser extent, /r/DevOps on Reddit, you know that urgency may even be too gentle a word. Some management teams seem to be in panic mode—you are going to have to live with some of these choices for a while, don’t make them knee-jerk.

    Normally, an MSP is your friend when moving like this, offering expertise and knowledge your organization doesn’t have internally, and shortening both deployment and the learning curve. But consensus is that MSPs, laptop manufacturers and VPN vendors are going to be booked solid for the near term.

    So, choose software when you can. Not because software is better (truly for some functions it is worse), but because it is generally easier to replace. A software VPN can be expensive, but you’re not buying hardware that is a sunk cost. Consider short-term solutions such as Amazon Workspaces or possibly  Chrome Remote Desktop, old standbys like VNC or RDP (likely with VPN in both cases), file sharing with things such as Sharepoint or OneDrive. Later on, you can look at a Cloud NAS such as Nasuni, or a more solid remote access plan.

    Yes, all the suggestions above have things you need to worry about. No, not everything will be within your control. However, these things are easier to rectify on iteration than “We bought big solution X, and it doesn’t do Y, so we need to replace it.” Start with short-term solutions and improve them as you go–this is truly the DevOps way, but it is easy to lose as you’re looking for high-volume, perfect and urgent.

    IT workloads (particularly operations workloads) are going to increase for any organization that wasn’t already set up for broad remote work. There is no way around this fact. As someone suggested online, “Kiss your family, tell them you’ll see them in a couple months and get to it.”

    You’ve got this. The internet is loaded with information to help, places such as Spiceworks and Reddit have people willing to offer advice all day. Smaller MSPs are likely happy to talk with you as they attempt to grow their business. Determine what you need, how fast you need it and implement the best solution you can in the time available, aiming to improve it on the next iteration. And keep the wheels of business running.

    It’s a flu variant, not the black plague. Businesses that deal with this well will come out well. Right now, “Deal with it well” includes a lot of IT work: from continuity planning, to fast DevOps iterations, to getting people at home productive and supporting them through this.

    — Don Macvittie

  • What’s the Impact of DevOps on Business Continuity?

    What’s the Impact of DevOps on Business Continuity?

    Organizational requirements change rapidly. The strategic plan you created in the past and previously only updated annually is now out of date within a quarter.

    Agile and DevOps practices have been adopted to help resolve complex business issues in these times of flux through technology improvement, providing organizations with an increased certainty of intent, quality and safety.

    However, integrating the potential impact of Agile or DevOps into business continuity practices isn’t always considered a sound and highly valuable idea. The continuity of an organization is often considered important only after a crisis has occurred—the proverbial closing of the gate after the horse has bolted.

    Below are a few ways that business continuity capabilities need to change in light of the impact of Agile and DevOps.

    First, a Business Continuity Primer

    Maintaining business continuity in your organization:

    • Provides the ability to adapt as required to meet competitive, regulatory, organizational, technology or new market opportunities.
    • Provides your stakeholders, suppliers and, most importantly, customers and staff with the assurance the organization will remain a sound, going concern.

    For example, many organizations have a data repository in an application such as SAP, Oracle or SharePoint. This repository is saved into the cloud or other media daily or as needed.

    That is great. But if you mapped the processes used inside a department, you might find that employees download this data into Excel or some other tool and manipulate it for their own purposes. This is where the real work is being performed, and if this data is lost, the business continuity impact could be quite severe.

    DevOps and Business Continuity

    Agile and DevOps methodologies suggest that you design, create, test and release your technology changes in rapid cycles of two weeks or less, with any technology change introduced probably having a business process—and thus business continuity—impact.

    Therefore, whatever you release must always be ready for production. But how can you provide this level of assurance? This is how:

    • All “epics”—high-level business needs that are broken down into smaller stories—should also have a simple statement highlighting the impact of request.
    • All user stories should have tests to confirm the work being performed is as requested but also that they would be usable no matter where needed.
    • Feedback is provided to the development, infrastructure, cloud provider and product owner regarding the success of the tests.
    • Any issues need to be resolved before the work/change is released.
    • Issues and other lessons become part of the backlog of new work.
    • If a continuity test was not performed, then this user story is prioritized for completion in near future sprints.

    DevOps and Business Continuity Maturity Assessment Questions

    There’s a relatively simple way to understand how your organization’s business continuity capabilities stack up: Ask a number of focused questions (to the people who should be able to provide suitable answers).

    Start by asking:

    • How often do you test your code as you create it? (“Oh yes, we do that.”)
    • Do you always test before you go live? (“Oh yes, we do that.”)
    • How many of you create your code—be it infrastructure virtualization, new applications, internet, etc.—in environments that replicate, as close as possible, the production environment? (“Oh, hmm, no our environments are all different.”)

    Step it up with the “killer” questions:

    • How can you ensure that what you’re about to release is safe?
    • How can you ensure that the work you’ve done is not a waste?
    • How do you know that your organization can be kept “in business” and will not be exposed to an adverse effect from the change, or a business continuity situation?

    Understand How the Organization Relies on Technology

    As mentioned, business continuity is ultimately all about keeping your business in business, and thus there’s a need to understand how technology is employed to maintain:

    • Regulatory compliance.
    • Competitive advantage.
    • A safe place for your people and suppliers to work.
    • The needed access to your products or services.

    And thus, you will need to:

    • Map the various value streams of work performed.
    • Map the technology used at each step, down to workstation applications.
    • Quickly assess the impact of that stream being blocked or unavailable by a facilities, people or technology issue.
    • Create a plan to make that value stream as available as required.

    Organizations that have mature business continuity practices will, of course, also use technology to automate these activities. But they will also ensure that changes needed are tested as soon as possible in the product life cycle.

    If your tests are not performed in a production-like environment continuously, then how do you know you are ready and safe to go live? Go-live should not just encompass the new code but also the processes, training, security, continuity testing, organizational change and supplier update, if needed.

    Fortunately, the DevOps tools that support these capabilities are readily available and thus need to become part of any development, testing framework or infrastructure.

    Ultimately, it’s important to sufficiently invest in keeping your business in business. DevOps practices are another element to factor in to your organization’s business continuity management policies, processes and practices.

    — Sarah Lahav

  • Protecting Data in Public Cloud and Hybrid Cloud

    Protecting Data in Public Cloud and Hybrid Cloud

    Backup, business continuity (BC) and disaster recovery (DR) have all been a critical part of IT for over 30 years—ever since we began relying on technology to run our businesses. Traditional solutions were designed for the world of on-premises infrastructure and structured applications and relational databases. But the world is changing. In the last blog, I talked about the era of digital transformation and the impetus it has on rethinking and reinventing the fundamental backup and recovery architecture for workloads moving to the cloud and applications being born in the cloud.

    What Changed? Reinventing Backup and Recovery

    Application and data platforms are undergoing the biggest transformation since the dawn of computing. There are several forces at work:

    • New applications. The third-generation applications are geo-distributed, scale across multiple systems, always on and typically are deployed in a cloud-first model.
    • Existing applications are moving to the cloud. They aren’t going away, but companies are moving some or all of them to the cloud. They still need backup and recovery.
    • RPO and RTO windows are shrinking: Enterprises want “always-on” and gone are the days when you could do nightly backups.
    • Smaller companies will go all-in on public cloud. SMBs don’t want to be in the business of IT. They’ve been driving the rapid growth of cloud applications and platforms.
    • Enterprises will build hybrid clouds. Enterprises will deploy applications and data across on-premises and public cloud environments. Scale, compliance and other factors mean they’ll need to keep some systems on-premises.
    • Everyone will use multiple clouds. No one will bet their business on one cloud or one provider. Even now, enterprises are splitting workloads across clouds or cloud and on-premises. Development and test may use one cloud, while the same application might be deployed in a private cloud or a different public cloud.

    Cloud’s Impact on Backup, Recovery and Continuity

    Cloud gives organizations much more agility, operational savings, and a pay-as-you go model. Public cloud providers can also build much more resilient infrastructure. Amazon guarantees 99.95 percent availability for EC2 and 99.99 percent for S3; S3 is designed for 11 nines of data durability, with multiple availability zones. Because the cloud is so reliable—and cheap—it’s quickly becoming a backup target for on-premises data. But that shouldn’t trick us into believing backup and recovery are “built-in” when we run applications in the cloud. Even Amazon itself recommends backup services for all AWS-native applications and cloud databases.

    While service availability and data resiliency addresses infrastructure business continuity and disaster recovery, it doesn’t provide point-in-time recovery or application level intelligence for backup and recovery. As good as the cloud platforms are, they don’t protect against logical errors. And research shows 8 out of 10 errors are logical errors—data corruption, user errors.

    Existing Backup Products and the Cloud

    As we noted above, traditional backup and recovery products don’t meet the needs of cloud applications—even for existing applications that have moved to the cloud, and not just because they were built in a different era. Cloud and distributed architectures present several other challenges:

    • Cloud breaks the media server based architecture of traditional solutions. Cloud applications and data don’t reside on a specific array or disk, so you can’t easily back up what you can’t see. Backups also don’t capture configuration data in the cloud, such as AWS Cloud Formation templates.
    • Cloud doesn’t speak the same language. Legacy solutions talk to tape, disk or virtual disks. Backup and recovery in the cloud means integrating with the right protocols, such as the S3 API or Google Cloud Storage.
    • Backup appliances can’t be moved to the cloud. Existing backup appliances such as EMC Data Domain or NetBackup that work extremely well on-premises can’t be picked up and moved to the cloud.
    • Traditional backup agents won’t scale. If you could get a backup agent running in the cloud, it wouldn’t scale well across dozens or possibly hundreds of nodes.
    • VM is not the right layer of abstraction: This is precisely why the core principle of the Datos IO CODR architecture is a scalable application-centric view of data management and data protection that distinguishes it from conventional approaches. This is the exact reason why the CODR architecture introspects application data and uses global semantic de-duplication to achieve storage efficiencies, instead of relying on traditional de-duplication techniques which treat data as an opaque object (such as a VM or a LUN). The benefit of this approach is fine-grained and highly space-efficient data protection that can span clouds over network links.
    • Cloud Gateway or Migration Services: Unidirectional only.

    Data Protection Must Be Reinvented

    The problem of backup and recovery of cloud applications is novel as there are three critical things a cloud backup and recovery architecture should have:

    • Elastic compute only. The architecture should scale efficiently on elastic compute instances. There shouldn’t be any CapEx costs for servers or appliances.
    • No media servers. Backing up large, scale-out databases requires direct a parallel streaming architecture for data movement between the database and secondary storage. Legacy backup architectures rely on media servers that quickly would become choke points. Direct parallel streaming also allows the data to remain available in native formats.
    • Semantic deduplication. Scale-out application databases typically have a 3x replication factor. If you back up individual nodes or even manage to snapshot the whole database, two-thirds of the backup data is redundant. Over time, backups will be 75 percent to 80 percent inefficient without semantic deduplication that works across a distributed architecture.

    — Shalabh Goyal

  • Don’t Be Samsung: Here’s How You Can Protect Yourself

    Don’t Be Samsung: Here’s How You Can Protect Yourself

    Imagine a factory building 100,000 units a day, and you can see how a small error can have huge consequences. Now imagine that factory is a database.

    The world’s top smartphone maker this month pulled the plug on its $882 Galaxy Note 7 after phones overheated and caught fire, concluding in a disastrous recall for Samsung that could cost the company as much as $17 billion and shutter a global revenue stream. In an unprecedented move, Samsung has told mobile carriers to halt sales or exchanges of the device, requested that users to shut off their phones and issued a mass recall while the South Korean manufacturer investigates reports of fires in original and replacement Note 7s.

    This a scant two months after the Galaxy Note 7’s launch, a device that one TechCrunch consumer electronics expert raved as “undoubtedly one of the most iconic handsets around.” While it is not clear what caused these fires, there is speculation that it was due to a faulty component that interacts with the battery, rather than the battery itself.

    It goes without saying that there are ample opportunities for error in the assembly of a smartphone. The complicated, highly coordinated process is fraught with thousands of input touchpoints, from hard- and software components to tightly controlled manufacturing processes to manual labor. And though there may be countless checks and balances in place, mistakes do happen. What may seem to be an innocuous error, such as not sufficiently tightening a screw or the shorting of a circuit, in this case has led to epic consequences.

    The truth is, these instances happen more often than we think, and to technologies even more vital to the population than a personal smartphone.

    Consider today’s era of big data and cloud applications, where enterprise applications ingest and process vast amounts of information from various sources, often in real time, to deliver critical analytics, contextual information or business insights.

    This data has weight. It can influence whether fleets of airplanes are grounded at gates all across the country. It can restrict customers from accessing funds from online banking. It can dictate whether millions of online retail dollars go unspent. The reliance on accurate data, and its grip on lives and business, is growing at an exponential rate—like ever-widening ripples in a lake.

    To support all of this data, new applications (such as real-time analytics, internet of things, ecommerce and others) are developed and deployed on scale-out, non-relational databases or ported from traditional relational databases.

    But, like the manufacturing gaffs experienced by Samsung, corruptions and operational errors by developers occur in enterprise IT environments. Enterprises know this, and billions have been invested in traditional backup and recovery and data protection products to protect against such “err” moments. However, the irony is that data protection products like those that exist for traditional relational databases do not exist for today’s modern, next-generation scale-out databases supplying the new types of data that increasingly control our lives. We’re essentially trusting that the Ma Bell rotary phone repairman will be able to recover personal data—such as contacts, photos and messages—after your Galaxy Note 7 starts smoldering.

    So how did we get from the world’s most explosive phablet to distributed databases and big data? Because, like the Galaxy Note 7, the tiniest data error can rapidly expand into magnificent, catastrophic consequences.

    Enterprises are adopting cloud applications that gather large amounts of data at a high-ingestion rate and process that data in real-time to deliver actionable insights. These applications are deployed on non-relational databases. As migration to cloud and multi-cloud application environments increases, enterprises also must be able to manage and recover at scale without data loss or corruption and with minimal application downtime.

    However, enterprises today face a significant gap in addressing their data protection requirements. Their most valuable data, often needed 24/7 and without fail, runs absent any point-in-time backup options for that ‘“Houston, we have a problem”’ moment. Most studies suggest that more than half of data downtime and loss is triggered by human error, corruption or virus attacks. And yes, while native replication helps enterprises meet business continuity and disaster recovery requirements by providing protection from hardware failures or even natural disasters, it is insufficient (meaning it cannot scale) to meet next-gen enterprise data protection demands. Case in point: If a minor schema corruption impacts the primary data copy, it causes a multitudinous ripple effect that impacts all replicas down the line. Yet, even without protection, industries continue to adopt and deploy scale-out database systems at an accelerated pace.

    So just as Samsung witnessed an error replicate itself into such a massive meltdown of global proportions that it threatens to kill an entire product line, organizations also must understand how replication-based protection mechanism can actually act like a virus—spreading a corruption uncontrollably across non-relational, cloud databases.

    Samsung’s troubles won’t end with the simple recall of a single product, and their predicament should resonate. There will be punitive measures, and perhaps even a total enterprise shift from the smartphone market. It is not an enviable position, but is does offer a clear example of how a peripheral manufacturing error can swell to engulf an entire brand.

    For enterprises rushing to deploy scale-out databases, let Samsung serve as a warning: that deploying any infrastructure that could potentially lead to exponential, irreversible corruption of all data copies is a recipe for harm (if not disaster). As enterprises make the switch to next-gen applications running on scale-out, non-relational databases, an assembly line e-stop needs to be built in, in the form of a point-in-time, version-friendly data protection solution.

    Data corruption is not a matter of “if,” but “when.” So have a kill switch ready.

    errors-replicating-image

    — Brian Yin

  • Enlisting the C-Suite in Disaster Recovery Initiatives

    Enlisting the C-Suite in Disaster Recovery Initiatives

    When disasters make headlines, corporate executives often have knee-jerk reactions and call for business continuity solutions to be implemented immediately. However, when push comes to shove, those very same executives tend to put up roadblocks with concerns over budget, priorities, vulnerability assessments and security.

    Perhaps more concerning, according to a June 2015 Ponemon Institute report, there are “a large portion of companies who remain vulnerable as a result of lack of executive interest in preparing for worst-case scenarios.” This creates a precarious situation for DevOps professionals that understand the severity and breadth of threats that can trigger downtime—from human error to power outages, cyberattacks and natural disasters.

    To expedite disaster recovery initiatives, IT teams must enlist top executives that influence budgeting directly. This often calls for varied approaches that speak to specific executive concerns and issues.

    Understand Your Options: Disaster Recovery vs. Backup

    It’s very common for companies to confuse disaster recovery and backup solutions. Both are available via cloud, giving teams access to capabilities that were once only available to enterprises with huge IT footprints. When you approach any executive, it’s critical to understand various services and how they can work in tandem to deliver the most cost-effective protection.

    Backup ensures companies do not completely lose data because it is backed up with copies. While it is important to have copies of data, accessing and restoring backups can take some time. Therefore, for workloads with important but not extremely time-sensitive data, backup can be sufficient while satisfying budget restrictions. In the fast-paced DevOps world, backup usually falls short.

    On the other hand, cloud-based disaster recovery ensures minimal—if any—downtime. Applications can fail over and be up in running in seconds. Further, testing can be done at will without any impact on production environments. For workloads that demand continuity of service and aggressive recovery point objectives (RPOs), disaster recovery solutions are the better option and can also deliver cost efficiencies.

    For many operational and regulatory compliance reasons, companies may require a mix of both backup and disaster recovery. When evaluating service providers, check into how easy it is to apply backup and disaster recovery based on your development and application requirements. Take a close look at pricing models associated with each—including any support fees.

    CEO/COO – Chief Executive Officer and/or Chief Operations Officer

    While CEOs and COOs generally delegate detailed budget decisions to their teams, they are still ultimately responsible for overall company performance and reputation. Anything that threatens ongoing conduct of the business is their purview. Be prepared to discuss risks in real terms, and clarify that a “disaster” can be triggered by something as simple as human error.  They will care most about considerations such as:

    • Time to business resumption [e.g. near-zero recovery time objective (RTO)]
    • Capital investment via pay-as-you-go options
    • Ability to prioritize data and workloads, both for budgetary and business continuity purposes
    • Data loss estimates, in the case of a disaster
    • Testing flexibility, to ensure an operational, reliable solution
    • Independent validation from similar customers or analysts that a solution is reliable, proven and cost-effective

    CIO – Chief Information Officer

    Theoretically, this should be the easiest executive to convince because the CIO has a personal stake in recovery, but remember CIOs have a tough balancing act between controlling budgets and limiting exposure. The 6 Disaster Recovery Doppelgangers quiz and e-book can help CIOs approach their disaster recovery challenges across the organization. CIOs generally focus on:

    • Ability to see and manage the recovery process
    • Scalability of resources with on-demand access, often honing in on flexible terms
    • Security and compliance capabilities and support
    • Testing at will to ensure solution performs despite configuration changes to the day-to-day operational environment

    CFO – Chief Financial Officer

    Everything boils down to financials for CFOs, so they should be approached from a fiscal angle that demonstrates value backed by metrics. Be prepared with unbiased, independent information that appeals to their risk averse nature. What other financial benefits might come from leveraging cloud-based disaster recovery? For example, in some cases DevOps teams are beginning to use the failover cloud as a load testing environment that would otherwise require significant on-premise investments. Disaster recovery-as-a-service (DRaaS) environments with advanced security can also be used to check for possible vulnerabilities to cyberthreats.

    CFOs often care about:

    • Flexible pricing options that can be tailored at a granular level based on services required
    • Pay-as-you-go pricing models that avoid upfront capital investment
    • Geographic constraints on their data, particularly if backups or failovers need to be maintained in a specific location due to jurisdiction requirements
    • Extended DR use cases that could offset other costs like security testing and quality assurance

    CMO – Chief Marketing Officer

    On top of branding, advertising and public relations responsibilities, CMOs have key objectives that pertain to customer loyalty and overall corporate reputation. They may not be interested in the details of services, but can be a powerful advocate that can speak to the need for business continuity solutions that will protect brand image, reinforce messages about your technology innovation and maintain excellent customer support. Familiarize yourself with real-world stories that demonstrate how media—both traditional and social—cover outages and their negative impact to business. One need not look further than the recent Delta and Southwest outages.

    The concept of DevOps is about culture as much as it is about technology, and communication and collaboration are key. By understanding the needs and responsibilities of all stakeholders involved, teams can cut through politics, efficiently protect business and begin to leverage cloud-based DR technologies for initiatives far beyond recovery, alone.

    About the Author / Lilac Schoenbeck

    iLand Head Shots 4/22/14

    Lilac Schoenbeck is vice president of Product Management and Marketing at iLand. She has nearly 20 years of experience with product management, marketing, strategy, business development and software engineering in the grid, virtualization and cloud domains. She is currently vice president of marketing at iland, a global enterprise cloud hosting provider. Prior to this role, she led cloud and automation marketing for BMC Software and has worked for IBM, Fortisphere, Innosight and the Globus Alliance. Lilac holds an MBA from MIT Sloan School of Management and a Computer Science degree from Pacific Lutheran University.