devopsy.kinsta.cloud

Tag: cloud

  • Automic empowers cloud Continuous Delivery with OpenStack Integration

    SEATTLE, Wash. & VIENNA–(Business Wire)–Automic, the leader in Business Automation today announced integration with OpenStack, one of the leading open-source software platforms for cloud computing. The new OpenStack plug-in integrates with Automic Release Automation, enabling users to streamline deployment and provisioning of OpenStack computing resources alongside application components and new versions, resulting in the Continuous Delivery of applications to the cloud. The OpenStack action pack is available immediately from the Automic Marketplace.

    The Automic OpenStack action pack uniquely supports the efforts of DevOps engineers, developers, and system administrators to help them create, deploy, and run applications by automatically provisioning or de-provisioning OpenStack environments in the cloud.

    The Automic OpenStack action pack enables users to:

    • Automate the server compute pool in an OpenStack cloud environment. Activities include creating, starting, stopping, deleting and configuring compute resources. Some of the typical use cases include setting up and destroying environments on demand and per schedule (for test environments for example).
    • Dynamically scaling up and down an existing compute environment using automation.
    • Manage configuration changes in an existing environment.

    “We are delighted to add OpenStack to the list of integrations that we currently offer our customers on the Automic Marketplace” said John Purrier, Chief Technology Officer of Automic, and a founder of OpenStack. “As organizations drive adoption of both Cloud infrastructures and DevOps practices, Application Release Automation supports the need to orchestrate and automate both sides of the fence while providing a completeContinuous Delivery mechanism for DevOps teams. Adding OpenStack to our existing list of integrations is a natural progression of our offering, driven by the demands of our customers.”

    The DevOps movement is a natural extension of the increase in the enterprise open source and hybrid Cloud adoption. While a big chunk of the DevOps movement is spearheaded by development, operations are usually in the driver’s seat for Cloud adoption at enterprises. DevOps is the critical enabler of the Continuous Delivery pipeline, one that seamlessly connects developers and operations.

    A hybrid Cloud strategy is the predominant choice of most enterprise IT departments, while OpenStack is leading in the open source software space for creating private and public Clouds. With hundreds of the world’s leading organizations relying on OpenStack and a projected CAGR of 31%, OpenStack is core to many organizations’ hybrid Cloud strategy.

    Tweet this:

    #DevOps deployment in the cloud. @Automic announces integration with @OpenStack. Available now at https://marketplace.automic.com

    Additional information

    Connect with Automic on Twitter and LinkedIn

    Availability and pricing:

    The plugin is available from the Automic Marketplace. The OpenStack plug-in is free for Automic Release Automation Customers. Pricing is on demand for non-Automic customers.

    About Automic

    Automic, a leader in business automation, helps enterprises drive competitive advantage by automating their IT and business systems – from on-premise to the Cloud, Big Data and the Internet of Things. With offices worldwide, Automic powers over 2,600 customers including Bosch, Netflix, eBay, AMC Theatres, Carphone Warehouse, ExxonMobil, BT Global Services, Société Générale, NHS SBS, General Electric and Swisscom. More information can be found at www.automic.com.

    Automic
    Courtney Glymph
    Courtney.glymph@automic.com
    +447584058886

  • Cloud Security: Software Defined. Event Driven. Awesome.

    Cloud Security: Software Defined. Event Driven. Awesome.

    I get it. Cloud and DevOps are disruptive and create new risks. I’m a security pro; one with decades of hard-earned experience telling me that with great chaos comes great opportunity… for the bad as much as the good. And once again it’s time to circle the wagons, make sure policies are enforced, and our organization’s are protected. Or maybe that’s just all the subliminal vendor FUD leaking past my mental firewalls.

    But maybe it’s time to tell that part of my brain to shut the blank up and start looking for all the ways cloud and DevOps make things better for security. Because they do. And not merely on the surface, but in deeply fundamental changes that upend a lot of our previous conceptions. The best part is that, for once, all of this is real, practical, and achievable today.

    Major cloud providers provide solid security foundations (otherwise no one can use them), typically better than most self-managed data centers. Great baseline security is all well and good, but I’m far more interesting in ways cloud enables us to do security better. Not a little better, but fundamentally improve our existing practices, processes, and capabilities. This isn’t a theoretical concept, but a practical one that some of us are using today in the real world, and I’m going to show you a concrete example.

    These capabilities are thanks to Software Defined Security and Event Driven Security.

    Software Defined Security is the ability to programmatically manage our security technologies, including the security capabilities of non-security technologies. For the most part it’s been an abysmal failure since security companies don’t exactly have the best track record when it comes to APIs and automation (well, outside of marketing materials). Even today the burgeoning on-premise automation tools often find themselves having to remotely log into consoles and issue command lines to manage activity. Security automation has usually been a good way to automate your rapid departure from your current employer.

    Cloud computing changes that in two ways. First, the broad accessibility of robust REST-based APIs to manage security features of cloud services and, on occasion, security tools or services themselves. SOAP APIs are usually too difficult to work with for anyone short of dedicated developers, while REST is often consumable for strong scripters and admins. Second, the non-security APIs allow security professionals to integrate with the infrastructure and platforms directly. We now use the same interfaces as operations and development, except we can use them to achieve security objectives.

    For example, at various conferences I demonstrate an automated incident response workflow that quarantines and instance, locks down the AWS management, images the storage, launches a forensics analysis server and connects the images, and performs a deep analysis of it’s state, connected resources, and potential exposure. An old version is up on GitHub and I have a vastly updated version I’ll be releasing soon. All of this happens in a few seconds.

    Another example, in that same project, nearly instantly identifies any instance in your account not managed by Chef. Identifying unmanaged servers in a traditional network is a common audit function that takes weeks or months. In cloud computing it’s two API calls and a three line comparison function. Last year at the RSA Conference I demonstrated automatically inserting a cloud WAF in front of detected web servers in less than a minute.

    The second piece of the puzzle is newer. With Event Driven Security we leverage the core instrumentation of infrastructure and platforms to detect events and initiate security automation. Until now nearly all security tools relied on polling/scanning or custom agents that have a pesky tendency to kill performance or otherwise break things. For example, instead of scanning the network to detect a change, the network tells us when it changes, and that event triggers actions. It’s a subset of Software Defined Security, yet still distinct.

    In this example I posted earlier this week I leverage Amazon’s new CloudWatch events and Lambda to automatically revert any security group changes, or only changes that fail to meet certain criteria, within 10 seconds. You could use the some template to reverse nearly any change in your environment, or kick off more complex workflows like the automated incident response.

    Software Defined Security allows us to build security operations that are as elastic and agile as the cloud itself. Event Driven Security further reduces the changes of manual error, bringing even greater automation and speed, especially when paired with frameworks and concepts like DevOps and immutable infrastructure. These aren’t new concepts, but unlike in the past they are viable and actively used by real organizations in real production environments.

    The combination fundamentally changes how we can build our security programs. Yes, we can still do all the old things we’ve always done, but with a little creative thinking we gain entirely new, and practical, capabilities. It’s a ridiculously exciting time for our community and profession.

  • Jelastic is Now Available on MoldData Cloud

    Jelastic and MoldData Cloud has partnered to enable DevOps with the containerized PaaS and meet the requirements of each specific business in the Republic of Moldova

    Palo Alto, Calif (PRWEB) February 02, 2016

    Jelastic, Inc., the first DevOps PaaS with native PHP 7 support within the cloud market today announced MoldData Cloud as their new partner, that is headquartered in the Republic of Moldova.

    Dorian Bodiu, CTO of S.E. MoldData about their cooperation with Jelastic:

    “We consider Jelastic as the best platform for us to satisfy the highest demands and needs of our customers. Jelastic is the production-ready solution with support of Docker containers technology, that enables DevOps to build, ship and run distributed applications anywhere. That is why this technology is taken as the main basis for the future business strategy of MoldData. From now MoldData will provide autoscaling feature, – the best argument for the customers who want to pay only for what they consume.”

    Jelastic enables the DevOps teams to easily create, test and run their projects using the advanced and user-friendly cloud platform. Developers also get the full package of advantages from Docker containers, such as smart distribution of containers, automatic vertical and horizontal scaling, full isolation and security as well as high availability. Jelastic is designed to provide the absolute ease of use for developers to create, run and scale applications in the cloud environment.

    “We are excited to expand Jelastic Ecosystem with MoldData Cloud, providing the ultimate containerized PaaS to web developers in the Republic of Moldova. Flexible pricing and high performance of MoldData Cloud in combination with Jelastic global technology provide new opportunities and high level of automation for DevOps teams within the local data center.” declared Ruslan Synytsky, Jelastic CEO

    MoldData Cloud customers value the personalized approach, as well as the high level of service and the best pricing offering within the market. Company offers a lot of services, as Virtual servers, Virtual datacenter, Web projects consulting, Dedicated Servers, Domain registration, Managed hosting, Server Management, Support center and Backup. The location of MoldData Cloud data center will ensure providing services in accordance with national standards of data protection and security, and with 24/7 technical support. Among the chief goals of MoldData are: performance optimization of users` applications and providing the highly qualified services. They are working with each customer directly to identify the size and type of project, its needs and the potential growth in order to meet the requirements of each specific business.

    With MoldData Cloud solution, developers can value all the benefits of DevOps PaaS, such as:

    • Automatic Horizontal and Vertical Scaling
    • High-Availability
    • Advanced Docker Support
    • Zero-code-changes
    • Clustered Solutions with Multi-Nodes
    • Application Lifecycle Management,
    • Custom and Jelastic SSL
    • SSH Access and open API
    • Marketplace (one-click installation of the most popular applications)

    About Jelastic

    Jelastic is an enterprise DevOps PaaS for containers deployed on bare metal hardware or any cloud IaaS. Jelastic customers and partners, such as ISVs, hosting service providers, systems integrators, outsourcing companies, DevOps teams and enterprises, can choose between Public, Private, Hybrid and Multi-Cloud options. The platform provides certified containers for Java, PHP, Ruby, Node.js, Python and .NET and the ability to use custom Docker containers. Jelastic offers agile deployment models without coding to proprietary APIs, flexible automatic scaling for stateless and stateful applications, collaboration, access control, monitoring, backup and disaster recovery, built-in billing and business analytics tools, while driving down TCO with high density and hardware utilization. Jelastic multi-cloud functionality enables customers to achieve high-availability through geo-distribution across different data centers or clouds, easily relocate the projects to the superior hardware with the help of live environment migration, choose between higher quality or more cost affordable hardware and host applications with the trusted cloud vendors. For more information, visit us at http://www.jelastic.com

    For the original version on PRWeb visit:http://www.prweb.com/releases/2016/02/prweb13194788.htm

  • What happened to the “Ops” in “DevOps”?

    The wave of digital transformation that has been enabled by cloud computing has provided both new opportunities and fresh challenges. On one hand, it is now possible for application developers to provide innovative new functionality to end-users almost instantaneously. One the other hand, this agility has created an environment in which users expect constant improvements and demand ever-higher levels of service. Indeed, the need to increase agility and quality simultaneously is largely responsible for the growing popularity of DevOps practices.

    When I ask customers who say they are “doing DevOps”, the conversation always seems to revolve around speed. Iterate faster. Turn out more innovations and new features – multiple times a week. Pull in microservices from this cloud provider over here, program in polyglot languages over there, virtualize and automate everything on no-name infrastructure, and do it all as quickly as possible. Leverage continuous builds and immediately push to production in a perpetual beta model. Test only at code-time, or even not at all and instead let the end-users test it for you. Forget about run-time instrumentation and monitoring — just get the feature out the door, wait for social media to report any problems, and in the meantime, move on to coding the next feature.

    It all sounds fun and productive, in the same way that dot-com-era rapid application development was fun and productive. And it certainly can reduce the cycle time on new features and provide opportunities to introduce new innovations. But that scenario as described isn’t truly DevOps, and it is built around a dangerous assumption about unlimited end-user tolerance for failures.

    Take a break from coding the next feature, stop, and read the first paragraph again. If you look at it, the only actual “Ops” in it is the automation used to enable the development process and push to production. In other words, it’s all “Dev” – as if all important activities stop the moment an actual user touches the application. But does that make any sense? After all, aren’t we building all of these cool new features for end-users? And isn’t the reason that we want end-users to consume these features that the applications support a business goal of some kind? And for end-users to consume these features, isn’t it important that our applications actually work and provide high levels of service in production scenarios?

    Here are a few tips to ensure there is some “Ops” in your DevOps efforts.

    1. Stop denying there is a problem. IT Operations is “so ten years ago,” many say, because the infinite elasticity of cloud and built-in exception-handling of modern programming environments renders all of that old-school NOC stuff as antiquated as the pager those folks used to wear. But that assumption is patently incorrect – just look at November 2015’s “Black Friday” shopping season, which was a mess for many online retailers, as noted in the Wall Street Journal, Business Insider, CBC, Express and the Independent. IT Operations is more important now, not less. DevOps without Ops is not sufficient.
    1. Eliminate operational information silos so you eliminate finger-pointing. Collaboration is a central tenet of DevOps and yet most people troubleshoot through inefficient “war rooms” full of individual component owners who are feverishly looking through their individual consoles to try and ensure the problem isn’t with “their” stuff. Many of those well-intentioned component owners bang their own heads against the table in frustration about how hard it is to even access the information they need in the first place, not to mention the fun job of trying to manually correlate timestamps and hostnames between their and others’ individual operational data stores. There’s no reason to perpetuate the silos of yesteryear – instead, put your operational data in one place, and let today’s machine-learning-powered management tools do the heavy lifting for you. You will certainly reduce finger-pointing, troubleshoot faster, and you may be able to eliminate the “war room” entirely.
    1. Monitor what (really) matters – your actual end-users. The concept of real end-user monitoring (monitoring the actual activity inside of browsers, mobile devices, etc.) has been around for a while, yet remains an under-utilized capability in most DevOps organizations – perhaps because it used to be technically hard to implement. But that was in the past – today’s next-generation application performance monitoring tools make end-user instrumentation simple to deploy. It’s important to see real user activity not only because end-users are the whole point of the exercise, but because server-side monitoring alone doesn’t tell you what’s actually going on. As late as June 2014, in an Oracle Applications User Group/Unisphere survey entitled “Performance Under Pressure: The State of Enterprise Web App. Quality and Availability,” 85% of customers reported that usually learn about application problems from end-user complaints – a staggering number which is actually up from 79% in 2009. There is simply no excuse for such a reactive view of monitoring.
    1. It’s in the logs! Logs are everywhere, but most organizations don’t use them because they are overwhelmed – logs contain too much data, they are too widely dispersed and too hard for humans to decipher. However, logs represent one of the best ways for development and operations to collaborate together, since the logging that is enabled by application and platform developers only becomes full of information in production. Next-generation management clouds that are designed to ingest big data at enterprise-scale can cope with today’s log data volume and velocity – which can be on the order of terabytes per day. Once the information is collected, your unified management regime automatically takes you to the few individual rows in the few individual logs that correspond to the exact problem you’re looking for (at the moment you’re troubleshooting), this mountain of data can become a treasure trove of information. Similarly, if machine learning algorithms can discover patterns and anomalies automatically, your logs can become ongoing sources of high-value IT and business insights. The data is there, you just need to use it.
    1. Planning is an everyday activity. DevOps organizations are necessarily often focused “in the moment” – but future business results depend on accurate advance planning. In most organizations, planning takes place in artificial time windows (calendar year, budget year, off-season, etc.) with incomplete information and a whole lot of guessing – and is often performed by analysts with no direct connection to the operational context. Instead of viewing planning as a once-a-year exercise in an ivory tower, regularly leverage analytical capabilities against your unified store of operational information to answer a variety of forward-looking questions. Your DBA wants to know if she has enough database capacity for next year? Analyze at the individual instance level. Your marketing people are worried that you can’t support their upcoming launch? Analyze at the application level. Your CIO wants to know where people are spending their troubleshooting time and the corresponding health of your entire infrastructure? Analyze across your entire estate. If you’ve followed my advice in steps 1 through 4 above, you have all the data you need already available. Now it’s time to use it.

    But hang on a minute, you say. Let’s not forget that we are doing DevOps for speed – and all this management, while clearly useful, could take forever to implement and slow everything down in the process. A few years ago, you might have been right. But technology marches on and today’s cloud-based management regimes can be leveraged instantaneously, with no changes to your infrastructure, and start providing the kind of value you need within minutes. With cloud-based IT Operations Management, your DevOps efforts can truly combine development and operations best practices while still delivering the speed you need.

    No more excuses. Put the “Ops” back in DevOps.

    About the Author/Dan Koloski

    UntitledDan Koloski is a software industry expert with broad experience as both a technologist working on the IT side and as a management executive on the vendor side. Dan is a Senior Director of Product Management for Enterprise Manager – Oracle’s integrated IT operations and Hybrid Cloud Management product line. Dan holds a B.A. from Yale University and an M.B.A. from Harvard Business School.

  • The Growth in Data Center Uses for Shadow IT

    The Growth in Data Center Uses for Shadow IT

    Shadow IT is casting a long shadow over IT departments as more organizations react to changing demands from their customers, partners and regulators. Groups and individuals outside of IT are taking matters into their own hands by tapping new cloud-based applications and hosted data centers.

    Shadow IT involves any purchase of equipment, software or data center resources for uses outside of production IT. These purchases usually fall outside the IT budget as well. In many ways, this trend effectively cedes the influence and control of CIOs and IT managers to others within their organizations. According to at least one bold estimate, shadow IT is set to make up 90% of all IT purchases by 2020.

    becoming faster and easier to acquire cloud resources that take longer to get with traditional IT processes. It’s therefore hard to hold back the growth of shadow IT. For example, a test engineer who needs some servers for performance testing. Or a product manager who needs some machines for internal training. Setting up a few AWS instances could take a matter of minutes – you just need a credit card. That seriously lowers the motivation to start requesting those resources from IT, explain why you need them, get approval, and then wait for manual allocation or completion of the purchasing process. As everything gets faster, online, and more automated, the line of business cannot afford to wait.

    Let’s examine the main uses of shadow IT to get a better understanding of what is happening.

    Uses Cases for Development and Testing

    Developers and test engineers are under huge pressure to be more agile. Even in organizations that we would never think of as “fast,” the pace changes rapidly. In heavier organizations that spent years establishing well-groomed IT processes, the dev/test consumer’s patience is running low. We are officially at a point where swiping a credit card and expensing an AWS instance has become easier than opening a ticket to request a virtual machine. As DevOps and automation cross borders and become mainstream, the need for speed makes Shadow IT thrive.

    Uses Cases for Sales Enablement

    Another line-of-business activity that’s implementing shadow IT involves the sales enablement process. This includes demos and proofs of concept, along with internal and external trainings, or customer support services.

    Until lately, most demos and proofs of concept were the responsibility of sales organizations, and such work was generally performed beyond the purview of IT. Now fewer companies are staging demos and proofs of concept at customer sites. They are adopting hosted data centers and web-based cloud services that customers and sales teams can access remotely through self-service.

    In recent years, many of these sales demos have been conducted at resellers and integrators, or by building a lab at a hosted data center where the infrastructure and software is housed.

    Uses Cases for Partner Enablement

    Shadow IT is also catching on for partner enablement to facilitate software development sandboxes, certifications, and testing of software-defined networks. Many industries depend on such product ecosystems for their long-term success. With software-defined infrastructure, the software can be easily integrated and controlled using outside tools.

    Most major hardware and software vendors are developing new partner labs. Members of the partner ecosystem can certify performance against the vendor’s equipment and interfaces without making big capital investments in the infrastructure themselves. Some examples include Cisco DevNet and Salesforce’s Force.com.

    Shadow IT Continues to Grow

    The organizations that adopt agility and DevOps are no longer the leanest and most cutting-edge. They can’t get away with a single Amazon instance. They need support for more complexity, more configurations and more context. They need to better mimic production, because more is at stake.

    As more lines-of-business in these organizations need to be faster, it’s becoming more challenging for IT to meet their needs with the Production IT toolbox – whether it is for development, testing, security certifications, demos or support.

    These kinds of use cases for shadow IT are on the rise, meaning shadow IT will continue to be a growth market for years to come. Whether or not shadow IT will consume 90% of all IT budgets remains to be seen, but it will definitely make up a significant portion of IT spending until production IT changes its approach.

    About the Author/Maya Ber Lerner

    image002Ber Lerner began her career with QualiSystems in 2007 and has steadily risen through the ranks in various roles starting as product manager, director of channel development, director of sales for APAC and Israel, senior director of international sales and, most recently, VP of sales, international. Ber Lerner holds a Bachelor’s degree with honors from Tel Aviv University in Biomedical Engineering.

  • How to prepare for a successful data migration

    How to prepare for a successful data migration

    It can be tough to find useful, concrete advice to assist you with an enterprise-level data migration project. There’s an awful lot that can go wrong. Common suggestions about finding the right people, minimizing risk, or employing an automated system that does everything for you, offer limited help.

    What you really need is a step-by-step checklist that you can work through.

    The success or failure of a data migration depends largely on how thoroughly and carefully you prepare for it. If we analyze large migration projects, we invariably find that the successes share many common characteristics. If you’re planning a data migration, these are the questions that you really need to answer:

    What type of data is being migrated?

    Not all data is created equal. There are various different types of data, so you need to be clear about exactly what you want to move.

    • NAS-based – Where network shares are migrated from one system to another.
    • LUN-based – Where the disks (LUNs) are migrated from one place to another, at block level.
    • VM-based – Where the entire virtual hosts are migrated from one hypervisor to another.
    • Application-specific – Where one set of databases or objects, is migrated from one host to another.

    What type of migration is it?

    Where your data is going, can make a big difference to your overall plan. Is this a local migration, within the same data center, a remote migration, shifting data from one center to another, or is it a cloud migration, where you might be moving data from one cloud provider to another?

    What is the current storage environment?

    You need a complete overview of your current storage environment before you move a single file. If you’re using SAN, then think about what hosts, in terms of operating systems and applications, are involved. What are the FC switches and RAIDs? Do you have a clear picture of all the inter-dependencies within the SAN? A deep understanding of the environment and its complexity, gives you a better chance of avoiding disaster.

    How much data is being migrated?

    An accurate estimate of the volume of data that needs to be moved is absolutely vital. You need to account for all the hosts, LUNs, and storage systems. It’s not enough to say how many terabytes of data need to be migrated, you’ll need a picture of how that breaks down before you can determine the time and effort required.

    How much time do you have?

    There’s always a deadline for any project. Your timeframe may ultimately be dictated by the volume of data and the migration rate, but you can only determine that rate with a complete understanding of the data, application, and environment. Can you migrate in a divide-and-conquer manner? The more you know, the easier it is to control operational complexity and reduce costs.

    How active is the data and how much downtime is possible?

    In order to determine whether the migration can be completed on time, or even at all, you need to know how active the data is. How much of an impact on production will be tolerated? Some downtime is inevitable, but it has to be worked out and agreed upon ahead of time. Creating the right strategy in advance, with all the key stakeholders, will dramatically boost your chances of success, and reduce stress levels on the day.

    What’s the right tool for the job?

    This is really going to depend on all of your answers so far. The right way to go about selecting is to draw up a list of evaluation criteria. Think about everything you need and create a list that you can cross-reference against the candidates.

    As an example, for a SAN migration, you might want something that offers the following:

    • A seamless installation with no disruption to the production environment.
    • A clear display for the automatically discovered SAN configuration, complete with identities, status, and I/O statistics for all hosts and LUNs to be migrated (as well as those not to be touched), so the migration operation can be organized correctly and accurately with high confidence.
    • The ability to migrate during non-production hours, or automatically yield to production traffic, with adjustable intensity/throttling.
    • A centralized reporting system that delivers the statistics you need.
    • Data integrity checking of intermediate images before cutover, so issues are flagged early before they can cause problems.
    • Secure wiping of the data disks after the data is successfully migrated out.

    When you’ve drawn up a list, you can apply it, and see how different options compare.

    Who are the right people for the job?

    A successful data migration is going to require some level of expertise. Ideally, you want experienced personnel to handle a process like this, and you may need to look externally to find them. If they can give you the answers you need to address the questions we’ve posed here in this article, then you know they’re qualified for the job.

    About the Author/Wai T. Lam

    CTOWaiLamCirrus

    Wai T. Lam is co-founder and CTO of Cirrus Data Solutions, a developer of Data Migration Server and Data Caching Server for storage area networks (SANs). He was previously CTO and VP of Engineering at FalconStor, a company he co-founded in 2000. There, he was the chief architect, holding 18 of 21 company patents. Wai received the prestigious China national “Top 1000 Technological Leaders” award in 2013.

  • How to align your DevOps and Cloud Initiatives

    How to align your DevOps and Cloud Initiatives

    Infrastructure-as-Code (IaC) practices, which in turn are made possible through infrastructure or platform clouds (IaaS or PaaS), solve many important issues related to continuous delivery and DevOps. Therefore, the implementation of IaaS and PaaS in a private, hybrid or public cloud model should always be aligned with your DevOps initiative. In a previous article, I argued that OpenStack is the ideal habitat for DevOps. After all, OpenStack is backed by some of the biggest companies in software development and hosting, as well as thousands of individual community members. Indeed, many argue that OpenStack is the real future of cloud computing. However, that cloud environment might also be based on proprietary VMware technology, hybrid Amazon Web Services (AWS) or similar. Whichever you end up choosing, the cloud is an important enabler for companies looking for continuous delivery in agile environments.

    Why? Why is IaaS an ingredientfor a successful DevOps strategy? Through IaaS and ultimately PaaS, the bottleneck of infrastructure provisioning gets resolved; No more dependency on busy ops teams with long task backlogs and not enough of people, who are able to script and automate. Infrastructure provisioning is required to create all sorts of environments on-demand, including development, test and integration environments, all of which are required in different phases or steps within the continuous delivery chain or release pipeline. These environments can be created in isolation and dependencies from other projects, which are responsible for so many delays in a release, disappear.

    Test automation is critical for continuous delivery, but benefits are diminished if the provisioning of the necessary test environment takes days or weeks.

    Tips for DevOps-cloud alignment

    So we’ve made the case for the cloud as part of a DevOps strategy. How do you now go about aligning your DevOps and cloud initiatives together? What factors do you need to take into consideration as your developers instantly spin up environments at any time?

    First, start with IaaS. IaaS is easier to implement and more commonly applicable than PaaS. For quick wins, use public IaaS such as through AWS or Microsoft Azure. Get the necessary compliance and security aspects for dev or test environments settled and create a couple of deployment scripts on top of these services. Either prepare ready-backed images with middleware, application servers and databases or leave it to developers to install these components on their own. Alternatively ops can also prepare necessary install scripts and provide them to development.

    Second, build your own IaaS, based on OpenStack or other technologies. The toolsets and interfaces used by the agile development teams and the team responsible for the IaaS infrastructure need to be synchronized. For example, if you’re using OpenStack for the cloud environment, align your provisioning tools around that, possibly using Chef or Puppet. The good news is that many of these technologies really work together well.

    Third, once your IaaS implementation is mature and has been adopted, move towards PaaS. PaaS is the champion’s league in private cloud and usually requires an organization to commit to certain standards for databases, middleware, application servers, deployment architecture and more. It makes it super-easy and fast to provision not only a server, but really the complete runtime environment of an application and deploy the application on top of it.

    In all phases there needs to be tight collaboration between the departments. Your agile development, IT operations and infrastructure teams responsible for delivering the private cloud all need to be aligned around the common goal: delivering quality apps and updates to market more quickly. That means working as one to build a reliable, fast and adaptive cloud infrastructure in support of agile services delivery. It is imperative to understand and track individual development milestones. There’s no point in relying on the ‘big bang’ approach: the cloud infrastructure needs to be synchronized with all the development timelines.

    It has been proven particularly useful to use agile methods in structuring the infrastructure teams: Each platform gets a product owner, who works with development teams and manages all the requests developers have for the platform, i.e. the required APIs and their signatures or supported versions of specific technologies in a common backlog. This is done in the same way as product owners in development are managing their backlogs for the business.,

    Finally, make sure you have the right skills in place. DevOps and private cloud infrastructures command new skills sets—operations engineers, for instance—to prepare, manage and develop your private cloud and the application platform. There’s no point in buying in skills half way through the agile development process: they need to be built into the business plan from the start.

    DevOps,IaaS and PaaS go together like the PC and the keyboard; apps and the iPhone; Windows and Word. Together, DevOps within an IaaS infrastructure enables you to harness faster development and move to continuous delivery.

  • Defining On-Prem

    Defining On-Prem

    Sometimes, the meaning of a word or a phrase changes so quickly that you don’t even notice that it’s changed; at some point, you just realize that you’ve been using it differently.  Take “on-prem,” for example. Not too long ago, if you said that a component of your IT system was on-prem, you meant that it was physically located at your facility. If it was hardware, the hardware was in the IT room down the hall. If it was software, it was running on a server in the IT room. But today it means something entirely different.

    (more…)

  • Q&A with Mark Carrizosa of Soha Systems on secure transition to DevOps and cloud computing

    Q&A with Mark Carrizosa of Soha Systems on secure transition to DevOps and cloud computing

    We recently spoke with Mark Carrizosa, vice president of security at secure application delivery service provider Soha Systems about the trends he sees with enterprises moving to cloud services. Prior to recently joining Soha Systems, Carrizosa held the position of principal security architect at Walmart where he developed and implemented the company’s global e-commerce security architecture framework. Prior to Walmart, Carrizosa held security positions at companies including Wells Fargo, where he analyzed the company’s infrastructure and application compliance to improve the security of both customer-facing and internal systems. Before that, Carrizosa held positions at Freeport-McMoran and PetSmart. This interview has been edited for brevity.

    devopsy.kinsta.cloud: With the rapid move to DevOps and cloud, are there opportunities to improve automation and for enterprises to do more with less? Or is DevOps moving so fast that there are additional challenges being created that outweigh some of the benefits?

    Carrizosa: In my opinion, and in my experience, particularly over the last few years in dealing with predominately DevOps shops, the challenges that we faced were not necessarily “can we automate something,” rather it’s “should we automate something.” There are absolutely some things that should not be left entirely out of the automation stream, but should have controls setup as a requirement at a staging gate. For example, you can automate the dynamic scanning your application for vulnerabilities, but what you also need is somebody to actually look at those applications and manually verify and make sense of the reports. These are key components in deploying and delivering secure applications.

    There are also ways to expedite processes by integrating certain security frameworks into your workflow, providing the right training, and also creating a shift in your culture. And DevOps, for the most part, is a good thing. It allows organizations to rapidly come to market.

    It’s also common in DevOps to have contentions between security and IT. The security group says “No, you can’t do this, it’s going to hurt us.” While the engineers say “We need this to push this out.” How well organizations manage these relationships is a mixed bag. But there is a formula for doing it successfully, and it is all about ingraining security into the culture, into the operations, so that you come out with a secure product and not have to remediate it once it’s done.

    devopsy.kinsta.cloud: When you’re constantly iterating and changing your infrastructure and deploying new apps and updates, how does that affect aspects of security that can’t be automated, such as threat modeling applications before they are built or changes are put in?

    Carrizosa: Threat modeling, while a new term, it’s not a new concept. If you think about risk management, typically audits are done at a point in time. But very good information assurance programs not only audit a point in time, but they implement a continuous model of checks and balances. So should threat modeling.

    Threat modeling needs to happen at inception to ensure that the concept is sound and the methodology is acceptable from a security perspective. But there should also be some levels of checks and balances to ensure that the baseline, or security posture, is maintained throughout the entire change management cycle from inception all the way to delivery.

    These are some of the things that can be embedded within DevOps and Agile. Microsoft has a very good, secure lifecycle management methodology that incorporates various elements of security checks throughout the entire development lifecycle. It’s something like this that needs to be included within these operations to ensure that every step you take has some level of checks and balances, whether it be automated or manual, to ensure that the process of an application or an environment is up to what organizations are requiring.

    devopsy.kinsta.cloud: There’s still considerable interest out there when it comes to how companies are meeting the challenges of moving to cloud services. Are there common threads you see out there when it comes to the challenges enterprises face when moving to cloud services?

    Carrizosa: Yes, absolutely, and one of the key factors is that organizations are looking for ways to securely move to the cloud, or move to a more shared compute environment while still maintaining the control and the reduction of risk that they are used to internally. I spent the majority of my career dealing with these topics from an enterprise level. Most recently at Walmart E-commerce, but I’ve also done the same for PetSmart, Wells Fargo, and some leading industrial companies throughout the industry.

    Some of the challenges that I faced have to do with public exposure. You have to deal with migrating from on-premises to cloud, and dealing with BYOD enterprise users. There are a number of potentially sensitive customer-facing applications or data sets that organizations are a little hesitant to move to, particularly at large organizations.

    Those large organizations are used to doing things a certain way. Time and time again I’ve heard the phrase, “but we’ve always done it this way.” That in essence could be some of the downfall, or some of the hesitance with these organizations in moving to the cloud, because they are not absolutely sure that they will maintain the control and the effectiveness for environments that they can’t manage.

    That’s what Soha is about. Soha allows these organizations to make that next step, to be able to take advantage of these cloud benefits, or even take advantage of some of the cost overhead and the security controls that they’re typically having to address at a high rate of cost and a great deal of effort.

    devopsy.kinsta.cloud: Broadly, considering a lot of the credit card and other significant breaches that have occurred in the past decade, do you think the sense of control enterprises have about how well their security and governance efforts are doing is illusionary?

    Carrizosa: Well, there’s that old adage of, “it’s never ‘if,’ it’s always ‘when.’ These recent breaches, for instance, are not necessarily based on the types of controls that organizations have, but a lot of times legacy controls or legacy approaches have always seemed to be good enough. And until there is some sort of catalyst to effect change, organizations aren’t necessarily going to stick their necks out. You have CIOs saying, “We do this, we do this, and we do this,” because that’s what they’ve always known. It’s time to now shift to a more open model. With that comes many risks, but in order to do so, there needs to be a fundamental change in the methodology of how organizations are tackling security.

  • Librato Seeks to Unlock DevOps Application Monitoring

    Librato Seeks to Unlock DevOps Application Monitoring

    As wider adoption of DevOps methodologies continues to foster demand for new tooling to help streamline evolving workflows, at least one vendor is attempting to address the growing need for related monitoring capabilities.

    Librato, a San Francisco-based provider of Amazon AWS applications performance monitoring (APM) services, claims that it is finding favor among the rapidly expanding DevOps community driven by its ability to inject critical visibility into the engineering lifecycle.

    Acquired by Austin, Texas-based SolarWinds in January for a lofty $40 million and renamed Librato SolarWinds Cloud, the company is touting its recent adoption by well-known providers such as Slack for monitoring of DevOps-centric applications performance and health metrics.

    “At its core, DevOps is destroying conventional wisdom around ritualized processes and the need to perform them, mostly in the domain of scale,” said Dave Josephsen, Developer Evangelist at Librato. “By attempting to include monitoring as a key element of the development lifecycle, this has created a whole new range of challenges, and opportunities.”

    By providing a centralized Web interface and open API to help create visibility into critical applications engineering requirements, Librato maintains that it is creating the tooling necessary to empower integrated development and deployment processes, such as continuous change control.

    “There are a lot of disparate tools for monitoring individual engineering tasks, but there hasn’t been any practical way to bubble up that data for efficient monitoring,” Josephsen said. “Within the context of DevOps, change control is a ritual that we’ve abandoned as we’ve embraced test driven development and automated away the human element, so there’s a distinct need for monitoring of feedback and metrics.”

    For example, cloud-based productivity messaging specialists Slack are using the Librato “StatsD” lightweight daemon process to stream business and app-health metrics regarding PHP applications into the monitoring platform. Slack also leverages Librato to chart data regarding connect, query and fetch latencies for its server clusters, and to monitor internal metrics about overall system health.

    “Having those graphs side-by-side lets us clearly see and compare the effects of network latency on one of our new services, and that’s very cool,” Richard Crowley, director of operations at Slack, wrote in a recent testimonial posted to the Librato Solarwinds blog.

    Industry experts agree that broader adoption of DevOps strategies will continue to drive demand for relevant monitoring tools, with solutions such as Librato seeking to deliver “modern stack architecture for looking at the modern stack.”

    “I think that APM is always interesting because it’s always new,” said James Governor, industry analyst with RedMonk. “The pace with which we’re building new architectures to deliver services to end users is increasing all the time, and with every new wave of technology, we tend to get new and associated models of APM tooling.”

    Librato is taking advantage of the need for a system that brings together the elements necessary for cloud native monitoring, and in an agentless manner different from other competing tools such as New Relic, the analyst noted.

    However, whether or not the platform is able to break down traditional engineering siloes to enable more efficient DevOps management, as Librato officials claim, remains to be seen, he said.

    “Each wave of technology has promised to do this, to remove the inherent finger pointing, and each has always made the same claim to break down organizational firewalls,” Governor said. “DevOps hasn’t boiled the ocean in this manner yet, but there are some unique opportunities; unlike previous waves, where automation was intended to replace humans, this is now about augmenting people, and we are seeing that teams are choosing new tools from which developers can truly derive value.”