staging-devopsy.kinsta.cloud

Tag: devops

  • Automic Software and Forest Technologies Announce Strategic Devops Partnership

    SEATTLE & VIENNA–(Business Wire)–Forest Technologies, the leading DevOps and Digital Transformation Consultancy headquartered in London, and Automic, the leader in Business Automation, today announced, a strategic partnership wherein Automic will leverage Forest’s experienced DevOps consulting and enablement capabilities to support their customers’ adoption of Application Release Automation and Continuous Delivery solutions, as well as provide input into their product roadmap.

    This Smart News Release features multimedia. View the full release here:http://www.businesswire.com/news/home/20160411005949/en/

    Under this partnership, Forest will include Automic solutions in its reference continuous delivery tool chain for their customers’ DevOps and digital transformation engagements. Every business relies on software to deliver value to its customers, and DevOps is the perfect catalyst for innovation in software development, and more importantly, a powerful tool for organizations looking to stay relevant in an ever-changing digital-led market. Software is more critical than ever.

    “Building on their 20 year heritage of automation in production environments for some of the largest companies in the world, Automic have delivered a truly Enterprise Class Release Automation product” said Andy Cureton, Founder and CEO of Forest Technologies. “We are excited to extend our existing relationship with Automic and are confident that by combining our expertise in delivering continuous delivery and transformation initiatives with Automic Release Automation we can ensure greater value.”

    “Forest Technologies shares the same strategic vision as Automic in terms of providing our customers with comprehensive Application Release Automation and DevOpssolutions. Working together, we enable synergies in our clients’ business processes and underlying IT infrastructure”, stated Todd DeLaughter, CEO of Automic Software.

    DeLaughter continued, “As an industry leader, Automic is solely focused on empowering businesses through automation, helping them to become more agile and responsive in this digital age. Our customers have been very clear about their intentions to align their business and IT needs, and as a result, we are proud to partner with Forest Technologies in order to jointly provide complete Application Release Automationsolutions to meet their needs.”

    The partnership enables Automic and Forest Technologies clients to enhance continuous delivery through end-to-end automation, while achieving greater agility and control. The expertise provided by both organizations will enable clients to adopt the necessary tools to begin their DevOps journey.

    Tweet this:

    Enable continuous delivery w/@Automic & @foresttechltd. Agility, speed & security are now part of your DevOps journey bit.ly/1Mmrx4x

    Additional Information:

    Connect with Automic on Twitter and LinkedIn

    Connect with Forest Technologies on Twitter and LinkedIn

    About Forest Technologies:

    Forest Technologies, a leader in automation, helps enterprises deliver software and software related services faster and at a lower cost through the adoption of DevOps and Continuous Delivery practices. Fanatical about customer service FOREST consultants are hired as much for their DNA as their ability. Established in 2003 with headquarters in London and offices in Singapore FOREST has over 100 customers from start-ups to enterprises across sectors including finance, retail, telco, and online gambling. More information can be found at www.forest-technologies.co.uk

    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, Vodafone, Société Générale, NHS SBS, General Electric and Swisscom. More information can be found at www.Automic.com.

    Automic
    Courtney Glymph
    Global PR and Communications
    +44 (0) 7584058886
    Courtney.glymph@Automic.com

  • SendGrid Reaches 1 Billion Emails Per Day Milestone 

    Customer Communication Messages Delivered via SendGrid’s Platform Engage 1.6 Billion Unique Email Addresses Every 90 Days
    BOULDER, Colo., April 11, 2016 — SendGrid, the leading delivery platform for customer communication, today announced that it has reached the milestone of sending 1 billion emails per day on behalf of its customers.  These customer communication messages reach more than 1.6 billion unique email addresses every 90 days and drive engagement and business growth for the 80,000 active SendGrid customers.
     
    “We’re proud of reaching this milestone and extremely grateful to all of our customers, partners, investors and employees who have helped us get here in the nearly 7 years since SendGrid was founded by Isaac, Jose and Tim,” said Sameer Dholakia, CEO of SendGrid. “As we celebrate this achievement, we are excited to continue building on our foundation of providing industry-leading email deliverability, scalability and support and striving ahead toward our vision of becoming the world’s most trusted communication platform.”
     
    With developer DNA at its core, SendGrid was founded in 2009 by 3 developers who set out to build a better way to send email. Together, they pioneered the transactional email category and today SendGrid is a leader in email infrastructure, having delivered nearly 600 billion emails to date.  The founders still write code every day and SendGrid’s scale, expertise and resources continue to help make its customer-senders successful. SendGrid offers strong inbox delivery rates, best-in-class scalability, and the largest support and account management services team in the industry.
     
    With the launch of Marketing Campaigns in December of 2015, SendGrid extended its customer communication platform. The new email marketing service empowers senders to deliver promotional emails that drive meaningful and lasting engagements, at a fraction of the cost of competitors.  SendGrid enables customers to execute and scale both their marketing and transactional email campaigns on one single platform. Since the launch, 9,000 active Marketing Campaigns customers have collectively sent over 500 million emails. 
     
    After graduating from TechStars in 2009, SendGrid has grown from 3 employees to 300. As part of its growth, the company now has:
    • 29 Support Agents who provide 24/7 global customer support via chat, email, and phone
    • 25 Delivery and Customer Success Managers 
    • 100 Engineers who contribute to a blistering pace of innovation and feature enhancement 
    • 350 customers who send 100 million emails or more via SendGrid per month
    • 8 Community Development Evangelists committed to helping the next generation of startup developers and founders grow their business across the globe  
    About SendGrid
    SendGrid is a proven, cloud-based customer communication platform that drives engagement and business growth. SendGrid is a leader in email deliverability and its proven, cloud-based platform successfully delivers over 23 billion emails each month for Internet and mobile-based customers like Airbnb, Pandora, HubSpot, Spotify, Uber and FourSquare as well as more traditional enterprises like Intuit and Costco. For more information, visit www.sendgrid.com.
     
    ###
  • FLAP, Part 3: Full Data Center Provisioning

    FLAP, Part 3: Full Data Center Provisioning

    In the first two parts of this series (Part 1, Part 2), we covered server provisioning and application provisioning. Knowing a bit about each of these tools is useful (although one blog is hardly a thorough evaluation of strengths and weaknesses—I strongly suggest you do more research), knowing how they work together is the point of full layer automated provisioning (FLAP). Automating one or the other helps, but automating both—and integrating that automation—brings us to the level of “Oh, engineering needs a new test environment, and it has to be internal …” and, with a push of a button, it is delivered. That should be the long-term end goal for your organization, so staff time is free to attend to some of the many other issues that plague any given IT organization.

    The thing is, these tools combine in both better and worse ways. Some are designed to work together as if one product; some take some work to get going but the combination adds value once connected; and some combinations are painful to put together and almost never are worth the effort.

    One thing you’ll note is a repeated discussion of OS support for combined solutions. The reason we address it here, even though we have limited words and it’s already been mentioned in product write-ups, is simple: The limitations of these combinations are compounded. That is, if the server provisioning tool doesn’t support Windows, then the complete solution does not, no matter what the application provisioning tool does. This applies both ways, and is an important consideration for most shops, so we mention it here.

    Tools Built to be Together

    First off, we’ll take the easy ones. These are the combinations that were designed to work together, and do so pretty well. They vary in maturity level, but otherwise, they’re good options if they fit into your environment.

    Razor and Puppet

    This is the easy one. Razor was built to be the server provisioning part of Puppet. While the solution set is relatively new, and it shows in the installation phase (which has several manual configuration steps both before and after Razor install), it is maturing rapidly, and the two dev teams work pretty closely together. This is one of only two solution sets that uses a single UI for all provisioning—in this case the Puppet UI. Support for operating systems is broad, including all versions of Linux and Windows to boot. (get it? To boot?) If your data center is highly heterogeneous, or you are already a Puppet shop, it is worth looking closely at this combination. You just have to keep in mind that it is improving at a rapid rate, so those things you don’t like likely will change soon.

    Satellite + Puppet + Foreman

    As of version 6.0, Satellite is a collection of tools knitted together that include Puppet with Foreman. This means that Red Hat has a vested interest in making certain the two tools work well together. And they certainly seem to. While the operating systems support is limited to Red Hat OSes, the solution is pretty rock solid, and like Razor and Puppet, it is improving at a rapid rate since the switch to this new platform. The UI is independent of the tools underneath, and this is the other solution that offers a “single pane of glass” for all installation activities. The one catch with Red Hat, as mentioned before, is that the functionality of underlying systems is only supported when used with Satellite. How that fits into your organization’s plans is up to you.

    Close Enough to be Second Cousins

    There are some combinations that, while not officially interdependent, have a long history of mutual support, and thus make them strong combinations. These tools tend to come with straightforward directions to make them work together, and those instructions generally work well. Once paired, they can manage complete automation in a relatively integrated fashion.

    Note that these combinations are not even a little exclusive. They are pairings the project teams saw made good sense, and have grown out of closeness. Both sides of these solution sets interoperate with other tools (see the next section).

    Ansible + Cobbler

    Ansible and Cobbler both trace their genesis to Red Hat, and they share some employees/team members—and have for a long time. That makes it natural that the two are closely integrated. Before Ansible started discussing all of the other server provisioning tools out there, it already had Cobbler integration.

    As one would expect, there is Ansible setup, Cobbler setup, and then integration. But once combined, Cobbler can do for bare metal, Ansible can do for cloud, and together they provide a full-stack solution. Since both support most operating systems, the final solution does, too.

    Juju + MaaS

    Juju and MaaS have interoperated for a long time. Both are projects of Canonical, so it is no surprise that their interoperability continues. Years ago this author used them together and it was … difficult. But that was years ago, and just in the last year both projects have made strides in documentation and ease of use. Like most solutions in this category, there are separate installations and then integration configuration. Since both support a large number of operating systems, this solution can manage the full data center also.

    Their traditional home, and the one you’re most likely to be comfortable with them in for the short term, is Ubuntu-heavy shops. But they do support most platforms out there, so it’s worth the time to look into them even for non-Ubuntu shops.

    The Extended and Mixed Families

    Then there are the ones that have not forged solid one-on-one relationships, some because they are forging a separate path and some because they want to interoperate with everyone. Note that some of the above systems meet this category—Puppet is integrated with most of the server provisioning tools out there—but due to space considerations, we’re not going to go over those products again here. This list contains both application provisioning and server provisioning tools not mentioned above.

    Chef

    Chef has put the bulk of its focus on cloud and virtualization, with the notable exception to this trend being in AIX, where it does support server provisioning. “The bulk of its focus” is not absolute, though, and that’s on purpose. Chef has had presenters at the annual conference talk about using it with server provisioning tools, so it isn’t unaware of the integrated solution space, just that’s not where their focus has been.

    SaltStack

    The Salt crew is happy to support everyone. While they don’t talk loudly about whom they are integrated with, the product is in use with most major server provisioning tools out there. As mentioned in the SaltStack write-up in part two of this series, cloud integration is pretty broad also, making Salt perhaps the most versatile of the application provisioning tools with regard to full data center automation.

    Stacki

    Originally built to interoperate with SaltStack, Stacki (disclaimer: this author’s employer) has moved on to support most of the availableapplication provisioning tools. The catch with Stacki is that some are supported with sample integrations and video tutorials at the open source layer, while others require a license and engagement of Stacki core engineers to obtain support. So there is a video showing Ansible and open-source Stacki working together and talking about the integration, but it would require a paid license and negotiation to get SaltStack or Chef with Stacki. Because of the way Stacki is designed, it is perhaps the easiest of all these products to integrate—simply add the appropriate “Pallet” and tell Stacki to include it in installations. It is getting the correct pallet that requires licensing for some platforms.

    Conclusion

    Since any server provisioning tool that allows users to customize the install can have the agents for a given application provisioning tool be the last step of a given install, these overviews are at least a little bit arbitrary. To be precise, they are easier to use in the given configurations, but all application provisioning tools can be forced to interoperate with any of the server provisioning tools listed.

    The point of this series was really to help those looking into full data center automation quickly get up to speed on what’s available in the marketplace, and as much information as a few 1,200-word blogs will allow to help shorten the list to ones relevant to your organization. It is by no means complete, and there are issues and concerns with each of the products that only further research will bring to light, so don’t stop here.

  • Continuous Testing Live Network DevOps

    Continuous Testing Live Network DevOps

    My earlier blog, “From Laboratories to DevOps: Factories for Continuous Testing,” discussed the importance of and suggested practices for a fully automated, orchestrated software DevOps laboratory infrastructure, akin to a modern factory staffed by robots churning out products at a dizzy pace. The blog applies to development of software for networks, and the practices increasingly are important as the network becomes more software-based thanks to software-defined networking (SDN),  network functions virtualization infrastructure (NFVI) and cloud-based networking. The edges of mobile networks, even the radio access networks, are becoming more software-dependent due to the need to position computing resources closer to mobile customers to resolve latency, bandwidth and spectrum concerns.

    However, the need for highly automated software processes does not stop within the development lab.

    At a recent DevOps Networking event in Santa Clara, California, Google Network Operations Manager Anees Shaikh indicated that Google’s live network has many thousands of nodes and management elements, supported by millions of lines of software-based configuration files that are updated tens of thousands of times per month. The sheer volume and speed of software updates for large networks is not feasible using manual methods. Automation tools for live network software updates are vital.

    Typical live network DevOps environments use DevOps continuous tool chains such as Git for software version management, YAML for defining abstract configuration definitions, Jinja2 to translate the configurations into concrete templates that can be consumed by real devices and Ansible for automating the distribution and activation of config files to the network nodes. But what about testing? How can a network operator be confident that the many updates will perform as expected once deployed across the live network? This requires much more than simple syntax and semantics checking of the config file entries.

    Recommended Practices for Continuous Testing of Live Network DevOps Environments

    For continuous testing of live network DevOps environments to work, here are some best practices to consider:

    1. Lab-to-live transition: Prior to deployment of any updates to the live network software updates should be tested in a lab environment using production-equivalent equipment and topologies.
    2. What to test? The actual tests to be executed depend on the risk of changes that are being deployed. If a small, low-risk configuration change is all that is being deployed, then a simple configuration check may be sufficient. On the other hand, if a change has the potential to disrupt the network performance significantly, then a much more comprehensive performance test is needed.
    3. Test orchestration tools: The test environment prior to deployment will vary depending on the tests that are selected. Test environment orchestration tools are needed to set up network test topologies that match the tests rapidly—and release them just as rapidly so the test resources can be used for the next tests.
    4. Elastic on-demand topologies: The ability to scale test resources horizontally and vertically, on-demand, is essential to be able to match the speed of testing required for short duration deployment cycles.
    5. Automate live network tests during deployment: To verify software updates do not interrupt or degrade network performance, functional and performance tests between pairs of nodes across the network mesh are required as the updates are deployed in stages across the live network nodes, clusters, centers and regions.
    6. Automate live network testing after deployment: After verifying that the deployments are successful, network tests need to be scheduled periodically to ensure latent problems with the new software do not impact the network.

    This is just a partial list of suggestions for continuous testing essentials for live network DevOps.

  • Submit your proposal for DevOps Enterprise Summit San Francisco!

    Submit your proposal for DevOps Enterprise Summit San Francisco!

    The theme for this year’s #DOES16 San Francisco conference is Leading Change.

    We want to hear stories from the leaders of large, complex organizations implementing DevOps principles and practices.

    The submission deadline is midnight PDT, May 2, 2016.

    All submissions will be notified by June 17, 2016.

    Get details >>>

    DevOps Enterprise Summit keynote

    DevOps Enterprise Summit

     

     

     

     

    DevOps Enterprise Summit

    DevOps Enterprise Summit

     

     

     

     

    This year’s programming will be based on a series of survey questions about the biggest issues IT professionals continue to work with. Several universal topics emerged, and we will be selecting talks that address them:

    People and Culture:  We’re interested in the strategies and methods you employed to successfully lead change and to enable DevOps outcomes in large organizations. How did your approach to leadership and organizational design differ from those used in more traditional IT organizations? How is the workforce different, both for employees as well as contractors and outsourcers? And what have been your results?

    Process and Technology: We are interested in the practices you have adopted to integrate change into your workforce and build on changing relationships with your vendors. What are modern architectural and technical practices that every technology leader needs to know about?

    Compliance and Security: We’re interested in concrete ways you have helped DevOps bridge the information security and compliance gap, showing auditors and regulators that effective controls exist to prevent, detect, and correct problems.
    Submit your proposal >>>

    For the full news release, click here.

    EARLY BIRD TICKETS ON SALE NOW!

    If you missed the Blind Bird tickets, don’t fret.

    We are offering a discounted Early Bird rate for  $1,450 (ends May 16). That’s a savings of more than 25% off the full-price ticket.

    We encourage you to act quickly as the past two years have sold out.

    Get tickets >>>

  • Full Stack Fest in Barcelona on September 5-9th

    Full Stack Fest will be held in Barcelona on September 5-9th, 2016. It will be comprised of two main blocks with a gap day™ in between.

    Let’s not forget that technology is made by people. That’s why we’re putting so many efforts in confirming industry leaders who will be speaking about topics such as the Erlang language & platform, the Interplanetary File System (IPFS), EcmaScript 6, Cycle.js, Functional Reactive programming, the Unison programming platform, Unikernels, scalable distributed systems, the Physical Web project, Web Assembly, CSS4, the Elm architecture and Serverless Framework, with many more to come!

    Call For Papers is open until May 14th with 16 speaker slots!

    You can read the details of our call for papers at our website —where people can submit their talk too.

    Also, here you have an online PDF with more information about the CFP’s press release.

  • Puppet Ignites Era of Constantly Modern Software

    PORTLAND, OR–(Marketwired – Apr 7, 2016) – Software underpins every part of modern life and commerce. Organizations rely on it to drive growth in all aspects of their business. According to market estimates, a $200 billion software infrastructure market is emerging as a result of mass migration to the cloud; pressure on IT to meet the demands of billions of consumers and business users; and the growing requirement to continually deploy and manage software to meet business goals.

    To help organizations compete effectively and thrive in a software-defined world, Puppet today announced its vision to give every organization the shortest path to better software. The company’s commitment to helping enterprises take full advantage of the movement towards constantly modern software is fulfilled by its industry-standard Puppet Enterprise platform. More than 30,000 companies around the world, including more than two-thirds of the Fortune 100, rely on Puppet Enterprise to continually deploy and manage software across their IT infrastructure, whether it’s physical, virtual, or in the cloud.

    “Software powers everything around us, from the devices on our wrists and our walls to the work we do, the fun we have, and everything in between. Modern cars are powered by millions of lines of code, our financial world is entirely mediated by software to enable speed and throughput, and it’s critical to delivery of core functions like medicine, utilities, and food. Nevertheless, most businesses take weeks, months, and even years to deliver everything from simple upgrades to the latest innovations, and too much of this software is out of date, insecure, and thus a barrier to progress rather than an enabler of it,” said Luke Kanies, Puppet founder and CEO. “With Puppet, customers build highly efficient DevOps practices that automate manual processes and get control of the entire infrastructure and application stack, eliminating constraints on innovation, securing critical capabilities, and maximizing the business potential from their software investments.”

    Opening the Gates to the Shortest Path to Better Software
    As part of the company’s strategic plan to make the shortest path to better software a reality for enterprises, Puppet also announced today new leadership, product updates, integrations, resources, and branding. All these elements support the company’s mission to help every organization significantly reduce the time it takes to provide both their internal and external customers with the most effective and modern software to achieve business goals.

    • Company name and brand refresh – The company is changing its name from “Puppet Labs” to simply “Puppet” to reflect the fact that the tight-knit Puppet community — tens of thousands of individual open source users and Puppet Enterprise customers — all refer to the company, the technology, and the community itself as “Puppet.” The new name, and a new brand identity to go with it, also reflect Puppet’s mission: helping every organization get on the shortest path to better software in service of its own customers and mission. For complete details, visit the new website at puppet.com.
    • First president and COO – Sanjay Mirchandani is the first executive to hold this position at Puppet. The former senior vice president of VMware will be responsible for Puppet’s go-to-market execution, including marketing, pre-sales engineering, sales, customer support, and services. For complete details, read our press release< (https://goo.gl/tKtnDO).
    • Project Blueshift and Puppet Enterprise 2016.1 – Blueshift represents Puppet’s engagement with leading-edge technologies and their communities — technologies like Docker, Mesos, and Kubernetes — and Puppet’s commitment to giving organizations the tools to build and operate constantly modern software. The new Puppet Enterprise 2016.1 gives customers direct control of — and real-time visibility into — the changes they need to push out, whether to an app running in a Kubernetes cluster or a fleet of VMs running in AWS. For complete details, (https://goo.gl/RTMS2v).
    • Atlassian HipChat integration – This new integration makes it possible for DevOps teams to direct change with the Puppet Orchestrator, see change as it occurs, then discuss and collaborate on changes in process — all right in HipChat. For complete details, read our press release (https://goo.gl/Xk2CrX).
    • Splunk integration – Proactive monitoring of infrastructure and applications is a key DevOps practice, enabling continuous improvement. The Puppet Enterprise App for Splunk now extends the Splunk platform to Puppet customers to diagnose issues and solve problems faster, so they can deploy critical changes with confidence. For complete details, read our press release (https://goo.gl/Fi9BFd).

    Additional Resources

    About Puppet
    Puppet is driving the movement to a world of unconstrained software change. Its revolutionary platform is the industry standard for automating the delivery and operation of the software that powers everything around us. More than 30,000 companies — including more than two thirds of the Fortune 100 — use Puppet’s open source and commercial solutions to adopt DevOps practices, achieve situational awareness and drive software change with confidence. Based in Portland, Oregon, Puppet is a privately held company with more than 400 employees around the world. Learn more at puppet.com.

    Press Contact:
    Justin Dorff
    (510) 875-9608
    pr@puppet.com

  • DevOps and Continuous Delivery: Not the Same

    DevOps and Continuous Delivery: Not the Same

    DevOps and continuous delivery are the same thing, right? Far from it. We peer through the fog to understand the difference between the two related but distinct methodologies.

    We live in an era of apps. More and more of our personal, social and work life is governed by apps—communicating with one another through social apps, booking cinema tickets through your mobile device or scheduling a business trip through the airline app. This digitization of services has arrived. Organizations that understand this sea change have a unique opportunity to jump ahead of their competitors, acquire customers more quickly and grow revenues.

    The battleground for this service development is DevOps. It’s not a product, but rather a methodology for helping organizations build teams and build software. DevOps is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other IT professionals while automating the process of software delivery and infrastructure changes. It creates a culture and environment where building, testing and releasing software can happen rapidly, frequently and more reliably.

    Organizations are marching with their feet. According to a recent study, market demand for DevOps skills is growing, and DevOps engineers are among the highest paid IT practitioners today. And it looks set to stay that way. Research in the U.K. shows that 30 percent of 300 organizations surveyed in the run up to the 2015 DevOps Summit had either started to implement a DevOps strategy or had already merged Dev and Ops, with another 13 percent planning to go down this route.

    Two Related Children: DevOps and Continuous Delivery

    So now we arrive at continuous delivery. If DevOps is about accelerating the delivery of new, high-quality services, surely continuous delivery is the same thing, isn’t it? In other words, ensuring a steady stream of new services? You might look at it as a manufacturing production line: DevOps is the machine that builds the service, while continuous delivery is the conveyer belt that rolls the services off the production line—one big unified service development cycle.

    That’s not the case. Although the distinction between DevOps and continuous delivery can be a little grey and cause confusion, there is in reality clear water between the two. Continuous delivery has become an essential ingredient for teams doing iterative and incremental software delivery. It is an approach whereby teams ensure that every change to the system can be released, and that any version can be released at the push of a button. Think of it this way: Continuous delivery aims to make releases dull and reliable, so organizations can deliver frequently, at less risk, and get feedback faster from the end users until deployment becomes an integral part of the business process and competitiveness of the enterprise.

    Gartner summed up the distinction between DevOps and continuous delivery very neatly with a report that stated, “DevOps is not a market, but a tool-centric philosophy that supports a Continuous Delivery value chain.” The analyst argues that bimodal and digital business strategies stimulate demand for improved speed and effectiveness of software delivery.

    Continuous delivery and DevOps do share common traits, though. Both methodologies are aimed at agile and lean thinking: each delivers small and quick changes; each relies on tight business an IT collaboration; and each share the common goal of faster time to market for new services.

    However, the goal of DevOps is merge dev and ops roles together—and the processes they manage—to achieve business goals. It’s all about a common, shared culture and enhanced collaboration. About clearly defined business processes.

    Automation has an essential role to play in both DevOps and continuous delivery. Automating DevOps helps your organization manage and secure continuous delivery to the business and IT users. The result is a faster, low-risk migration to a new world of composite applications, faster business innovation and better support for rapidly changing business process needs.

  • Threat Stack Cloud Security Platform™ Achieves AWS Security Competency

    Threat Stack Earns Competency for Comprehensive Security and Seamless Customer Experience

    BOSTON – April 7, 2016 – Threat Stack, a leader in cloud security management and compliance, today announced that it has achieved the Amazon Web Services (AWS) Security Competency as part of the AWS Competency Program for the Threat Stack Cloud Security PlatformTM(CSP).

    “Security starts with visibility and Threat Stack offers unparalleled visibility across our systems and cloud infrastructure,” said Chris Haag, Director of Engineering, Agari. “The Threat Stack Cloud Security Platform offers both intelligent anomaly detection and a highly flexible rules engine to detect suspicious behaviors such as privilege escalation, data exfiltration and unusual network activity.”

    The AWS Competency Program is designed to highlight members of the AWS Partner Network (APN) who have demonstrated technical proficiency and proven customer success in specialized solution areas such as Security. The Threat Stack Cloud Security Platform™ attained security competency based on proven success in building products and solutions on AWS to support customers in the area of configuration and vulnerability analysis.

    “We strongly believe that a layered approach to cloud security is best, which makes Threat Stack CSP an essential complement to AWS,” said Brian Ahern, chairman and CEO, Threat Stack. “Threat Stack provides the deep visibility needed to identify insider threats and intrusions, prevent data loss and meet compliance regulations when building and running on AWS. Achieving AWS Security Competency Partner recognition demonstrates our commitment to protecting customers’ workload and broader environment from threats.”

    Threat Stack CSP is an industry leading, fully integrated cloud security suite. Cloud-native and platform-independent, Threat Stack CSP measurably reduces the expense and complexity required to identify threats, keep data protected and automate compliance requirements. Threat Stack CSP offers instant visibility and deep correlated context that enables companies to operate efficiently, prevent data loss and identify and verify threats.

    About Threat Stack

    Threat Stack enables growth-driven companies to scale with confidence by identifying and verifying insider threats, external attacks and data loss in real-time. The only fully integrated, cloud-native continuous monitoring solution that gives companies instant visibility and automatically responds to changes in their environment, Threat Stack provides the coverage needed to run secure and compliant, in all environments, without sacrificing speed and efficiency. For more information, or to start a free trial, visit threatstack.com.

     

  • FLAP, Part 2: Application Provisioning

    FLAP, Part 2: Application Provisioning

    In part 1 of this series we talked about server provisioning tools. In that post, we mentioned some of the more prominent application provisioning tools on the market with regard to integrations. This post will focus on the application layer of full layer automated provisioning (FLAP).

    Application Provisioning Who’s Who

    Application provisioning technologies most likely are familiar: Puppet, Chef, Salt, etc. We’ll take a look at each, how they compare in the areas of control mechanisms, operating systems support and ease-of-use features (integration with server provisioning tools is mostly covered from a server provisioning tool perspective in part 1 and part 3 of this series, because integration must be managed in the server provisioning tool). A blog is too short to go much deeper than that, but this will help you determine which ones should be considered in your environment. Information here is valid as of the day this blog is written, but the market is moving fast, so don’t hesitate to check at the provided links for improvements. Because this topic is a popular one, don’t hesitate to look for up-to-date information provided by other sources, either.

    It is worth mentioning that all of these tools are moving to support configuration of network equipment. For a guy who spent years worrying about programmability and interoperability at a networking gear vendor, that is very cool news. I haven’t had time to actually try any of that support yet, so I’ll leave evaluations to you.

    A word of advice: This entire marketplace has cutesy-naming disease when it comes to really important concepts. While you are grimacing at “recipes” or “grains” or whatever, learn that terminology. It may be cutesy, but the heart and soul of these products hides behind those names and the details of what concepts they encapsulate. During your evaluation period preferably—but certainly once one is chosen—you should get those terms and their meanings down pat. It will make your life much easier. The same is true with the variety of scripting formats. They’re all communicating basically the same information, but so do English and Japanese—knowing one doesn’t automatically makes you an expert in the other. Take the time to truly understand the scripting language for your tool of choice.

    Ansible

    Ansible is a full-app provisioning tool that allows users to install and customize applications through a combination of a command line and scripts. The tool is well-documented, easy to install and works very well at its designed task. Ansible offers support for Red Hat and Windows running on Docker, OpenStack and AWS. Notably missing is VMware support, but since the machines are available via IP and the OSes are standardized, VMware virtuals can be managed/orchestrated with Ansible.

    The open source version of the tool comes with command line interfaces and management is handled via command line and editing scripts. The premium add-ons such as Tower include UI, analytics and programmable APIs.

    Since the purchase by Red Hat, it is reasonable to expect an increased focus on RHEL for this tool and a commensurate reduction in non-Red Hat OSes. Not that this is assured, but history says it is a likely long-term result. If you’re a Red Hat shop, Ansible is a good place to start—though looking at Satellite—and trying to predict how Red Hat’s various open and add-on provisioning tools will evolve and emerge—is a good idea for any evaluation at this point in time.

    Chef

    Chef is one of the original application provisioning tools out there. It is managed through command line and scripts in the open source version, and through these plus a GUI in premium. Unlike Ansible, many Chef APIs are bundled with the open source product, only APIs for premium services like analytics and reporting are premium.

    Chef supports most variants of Linux and Windows, with most cloud and virtualization vendors available as platforms. In terms of completeness of support, it really is up toward the top of the list.

    If you have a largely heterogeneous environment, Chef is a good tool to look at for automating application provisioning—be it for deployment, refresh or continuous delivery.

    Juju

    Juju advertises itself as an orchestration layer above the other products in this space. While there is a small amount of truth to that claim, most of what you can do in terms of orchestration with Juju can be done with the others. In fact, Puppet has kind of found a home in entire complex multi-server systems. Juju comes with GUI in the open source version, but the product does not have a traditional API.

    Juju supports Ubuntu and Windows, and is interoperable with most of the major cloud providers. Deep server provisioning integration is really only provided for MaaS (another Canonical project), but users have made it work with other server provisioning tools. Juju scripts (charms) are primarily written in Ruby, though other languages are definitely possible. For Ubuntu shops, Juju would be the item I’d place on the top of the application provisioning list. For Windows shops, it would definitely be worth considering. For Red Hat shops, other solutions are probably more appealing.

    Puppet

    Puppet should need no introduction to readers of staging-devopsy.kinsta.cloud. The standard in application provisioning, it uses scripts and command lines to deploy applications with a pretty broad base of user support that equates to lots of user shared scripts. Other vendors in this list also have vibrant communities contributing scripts, but Puppet, by sheer weight of numbers (and marketing), has a larger selection available.

    Supporting all major operating systems, Puppet’s documentation is solid. The only quibble is that you have to be careful when coming from a search engine about whether you’re on the open source documentation or the Professional Edition documentation. Puppet comes with APIs, though the GUI is only available in the commercial version. Puppet is the progenitor of Razor, the server provisioning tool, and while it has been used with all of the provisioning tools in the first iteration of this article, expect it to work best and provide the most value with Razor going forward.

    For highly heterogeneous shops, or shops that include multiple server provisioning tools, Puppet is a solid bet. While it will work fine in other situations, the value-add of a more focused product is worth considering if your environment maps to another tool’s strengths.

    SaltStack

    Salt is an interesting member of the application provisioning crowd. They don’t share name recognition with some of the other players, and yet have a respectable user base. Their product is certainly comparable to the others in this market, and the user community is pretty active. Not being deeply associated with any of the server provisioning tools, SaltStack has been integrated with most of them.

    The Salt Master runs on almost all flavors of Linux, and can manage all major Linux distributions plus Windows, OS X and Solaris.

    Like all of these other tools, SaltStack can manage any machine that is accessible over the network and is running a supported operating system., Additionally, the dev branch has Salt Cloud built in to the Salt Master, which spins up cloud images, automatically puts them into salt and starts managing their configuration. Expect that this type of functionality will become the norm for the market (Juju does some of this also, and others have varying levels of cloud support)—it just makes sense, and it compliments server provisioning. There is a tiny bit of overlap in the VM space, but then you can choose whether to use server provisioning or Salt Cloud to handle those instances.

    For highly heterogeneous shops that wish to use best-of-breed (actually “best fit” is a better name) server provisioning along with a solid application provisioning tool, SaltStack is a heavy hitter worth considering. If you have a more specialized environment focused on a single OS, SaltStack will work, but its advantage of broad support for both OS’s and server provisioning tools will not come into play.

    Satellite

    Satellite is Red Hat’s provisioning solution. Unlike most of the others in this list, it is a cross between server and application provisioning. In actuality, it is that “layer above provisioning” that Juju positions itself as. Under the covers, Satellite (as of release 6.0) is using Foreman for server provisioning and Puppet for application provisioning. The reason it still makes this list then is because it does do application provisioning, and does orchestration too. You can use it to spin up MariaDB or OpenStack, and it is a marketed and supported product, so it fits the list.

    As one might wholly expect, Satellite supports RHEL. It can manage instances of RHOSP and RHEV, along with VMware and Amazon, and does bare metal through Foreman also. Satellite is deeply tied to Foreman and Puppet, so if you have issues using this tool set, it’s not going to be your first choice. Because Satellite extends and improves Red Hat Network access, for Red Hat shops it should be No. 1 on the list of viable options, but if you use a lot of non-Red Hat machines, including (as of version 6) Fedora and CentOS, it is less appealing. It used to be that Spacewalk was the viable option for those CentOS and Fedora installs, but now they are separate code bases, meaning you have to maintain two different systems. At that point, it is worth looking at other options available on the market.

    The newer version 6 architecture is designed to provide a platform moving forward that is more powerful and adaptable, so expect to see good things from it if you are a Red Hat customer, possibly even cancelling out the disadvantage of no support for CentOS and Fedora.

    Summary

    All of these products are very good in their best environment, and most of them will give you pain in their very worst environment. The question is, which environment do you have? While only employees can answer that for a given environment/tool combination, hopefully there are some pointers here—and elsewhere—that can help make the decision.

    In the third and final installment, we’ll look at the combination of server and application provisioning to offer full stack automation.