devopsy.kinsta.cloud

Tag: cloud

  • The web-scale avalanche

    The web-scale avalanche

    Old-school businesses may not like it, but they’re competing with Google, Facebook, Amazon and other Internet powerhouses because those players have grown from day one with an eye on rapid, scalable, cloud-based and continuous IT operations.  

    Companies have been running application delivery aligned to an aging model based on low frequency release cycles. For decades, the major IT suppliers like Microsoft, Oracle, IBM, SAP and others have released software at the predictable, plodding cadence of annual or bi-annual releases. IT departments have adapted to the vendor release cycles with mirror-like processes: highly structured in the ITIL fashion with processes in place for working around lots of bugs that don’t get readily fixed by the vendors. Yet this delivery management model is now out of pace in today’s always-connected, Internet-based world in which apps and sites morph on a weekly or even daily basis.

    Suddenly, companies and vendors alike must change what they’ve been doing for years. They need to transform operations and products from the legacy-based delivery model to one which is faster, dynamic and proactive. But that’s hard for most companies. It’s like driving a 1979 Chevy pickup on the Autobahn. You can’t keep up with the pace of traffic, no matter how hard you try.

    Companies such as Facebook, Twitter and Netflix, born as Internet-age companies, don’t have the same problems adapting to modern times in which consumers expect instantaneous response times. They were built from the ground up to handle the relentless pace of technological change: their infrastructure and applications automatically shift according to network and CPU conditions and workload spikes. Such companies are masters at Web-Scale IT, and rely upon a multitude of open source and web-based technologies designed for distributed computing. More than just technology it also takes radically new processes and mindsets to become a Web-Scale IT company.

    Operating in the Web-Scale World

    Web-Scale IT consists of technologies and methodologies that enable developers to build, change and scale applications 10 to 100 times faster than in the past. Web-Scale IT relies upon many modern concepts, including cloud computing, peer-to-peer architecture, NoSQL, SOA, Agile development, DevOps, Continuous Delivery and Deployment and more.  Gartner describes Web-Scale IT as “a pattern of global-class computing that delivers the capabilities of large cloud service providers within an enterprise IT setting.” The research firm predicts that by 2017, Web Scale IT will be an architectural approach found in 50 percent of global enterprises, up from less than 10 percent in 2013. Below are a few areas of change that IT organizations must navigate to make the shift.

    1. Reevaluate IT partners. It’s not just CIOs that need to shift operations for Web-scale computing. The legacy IT vendors are struggling to walk away from profitable business models based on licensing to embrace the on-demand, services-based revenue that just a few years ago, catapulted startups like Salesforce.com into billion-dollar enterprises. The legacy vendors are unable to innovate fast enough and are having to rely on serial acquisitions to keep their technology relevant.  Yet rapid acquisition comes at a great price and is not sustainable. IT departments will need to look far and wide to find the best partners that can support their Web-Scale IT efforts moving forward.

    2. Acquire diverse, open-source based IT operations tools: CIOs will likely need to constantly review their technology sourcing and have a more critical method of choosing their technology partners. Relying on a few trusted long-term partners will likely not achieve the Web-scale IT goal. Consider that Netflix, which now runs its business almost exclusively on Amazon AWS, only a few years ago relied on its own datacenters full of legacy vendor equipment. Today, the company manages its high-availability video streaming business using a collection of inhouse-developed open source tools (coined The Simian Army) that test the fault tolerance of the company’s operations. Being flexible and open to change allows Web Scale companies to keep ahead of the competition. Standing still, even for a short while, is no longer an option.

    3. Foster iterative, collaborative processes: Strong DevOps cultures, where developers and IT operations personnel exchange information frequently to stay in step with changing business requirements, is also pivotal to making this shift. Companies with advanced DevOps practices are usually committed to running their businesses differently: more efficiently, more customer-focused and with the keen ability to respond quickly to change. CIOs and CTOs need people with strong Web technology skills yet also an unflinching commitment to collaboration and complex problem-solving. IT people today need to think on their feet and adapt as they go. Twelve-month planning cycles are out the window.

    The building of a storm

    Just a few years ago, it was considered evolutionary, if not revolutionary, to purchase CRM or HR as a service. That’s commonplace today. The next area for innovation is within core applications such as a retailer’s pricing application or a bank’s market forecasting tool. Those applications must now also run at Web Scale to be responsive, customer focused and speedy. Don’t count on your Oracle or SAP database to shift so easily or quickly—at least not yet. That’s why Internet leaders are managing IT infrastructure using the newer generation of Web Scale technologies including Puppet, Chef, AppDynamics, New Relic and yours truly, Boundary.

    If running at Web Scale sounds overly complex, it’s not. Since most of the latest, open source-based operational tools are highly automated, using them is actually simpler. Crowdsourcing is another strategy that companies are exploring for Agile development projects. The bigger hurdle is in moving from the old-fashioned software development style of over-engineering everything to the more intuitive, iterative style that characterizes modern Web application development. With Web-Scale IT, it’s okay to cut corners and take more risks, because the infrastructure will stand behind you.

    There are plenty of people who’ll disagree with me, but I can envision a world in which the Oracles and IBMs no longer run most of the companies in the world. — one that is adaptive, business-responsive and always forward-looking. The future is closer than we think. Will your business evolve?

  • Five Top Tips for Cloud and DevOps Automation

    Five Top Tips for Cloud and DevOps Automation

    A while back, I overheard someone asking why many of the ‘cloudy people’ have moved on to DevOps.

    One reason is certainly that cloud is at the heart of DevOps. Many of the grounding principles of DevOps – rapid iteration, agile development, automated testing, continuous delivery and continuous integration – are barely even possible without cloud. However, I think it runs even deeper than that. DevOps and Cloud are both fundamentally enabled by the same technology I have been working with my entire career – automation.

    When IT leaders get excited about cloud, it is mainly because of automation. Sure, cloud providers get excited about essential characteristics like broad network access and resource pooling, because that is how they maximize reach and minimize costs. Similarly, CFOs get excited about the measured service, because that means they only pay for what they use.

    However, according to a recent Luth Research study, most IT leaders prioritize the higher-order values enabled by on-demand self-service and rapid elasticity – faster innovation, superior performance, better scalability and higher resiliency. These capabilities are deeply rooted in automation – of provisioning, deployment, configuration, scale-up/scale-out and other processes.

    Similarly, DevOps – beyond a certain point – also builds on a foundation of automation. As Rackspace CTO John Engates noted in his recent column in this journal, “DevOps is more than a set of automation tools.” He is right, of course. You can achieve a great deal through cultural and structural changes – better collaboration, shared goals, team building, process improvements, etc.

    However, tools for release automation, configuration automation, process automation, test automation, service virtualization and provisioning – just to name a few – are adding tremendous value with a rapidly maturing DevOps automation toolchain. Indeed, in recent research from Vanson-Bourne, over half of senior IT decision-makers worldwide rate automation as the most important DevOps component – above such putative stalwarts as agile development, collaborative teaming and process alignment.

    Looking at the history of enterprise automation, and considering my own experience, I believe there are many common principles that you can apply to both cloud and DevOps. Here are just five of my top tips:

    Don’t Automate Bad Processes

    Automating bad process just makes bad things happen faster. This seems obvious, but I often see automation that only encodes (and accelerates) a bad existing practice. To avoid a high-speed train wreck, first identify, catalog, document, review and refine key manual processes to make sure you are automating the right activities, at the right time, in the right way. Solve for simplicity, speed and throughput, even before you apply automation. Remove friction across silo boundaries – departmental, technological and disciplinary. Start simple, be inquisitive, and iterate methodically. Then make sure you automate deeply, thoroughly and efficiently.

    Cross-skill Existing Resources

    Great people are hard to find and salaries for cloud- and devops-relevant skills are amongst the highest in IT. This explains why, according to the same Vanson Bourne research, over 70 percent of DevOps leaders are retraining existing personnel, while only 50 percent are hiring new resources. Look for staff with a history of automation in their resume, through multiple waves of technical change, rather than specialists in one automation technology or product. Find the IT equivalent of a “good athlete” rather than a “position player”.

    Security Cannot Be an Afterthought

    Automation systems and the staff responsible for them have always needed highly privileged (and frequently shared) user IDs, whether automating a mainframe IPL or scripting a production code release. This is an audit red flag, and can result in high-impact incidents, whether accidental or malicious. Identity and access management provides essential audit and control, while giving users (including automation tools and APIs) easy access to the resources they need (locally and in the cloud), when they need them.

    Document, Measure, and Backup

    If you do it right, automation quickly becomes pervasive and mission-critical. Without documentation, you create inscrutable systems, tribal knowledge, the hero and other ‘anti-patterns‘ in your Cloud or DevOps machine. Without measurement, you cannot know if (or when) complex autonomous systems run amok or stop working. Without backups, critical systems are prone to irrecoverable failure. Cloud and DevOps teams must value and prove traditional disciplines like documentation, measurement and backup – painful as they may be.

    Build Awareness into Automation

    As automation becomes mission-critical, it must be resilient to errors, failures, exceptions and other unexpected conditions, and still deliver a correct result. Remember when ‘autonomic computing’ was a thing, when we dreamt of ‘self-aware’ systems? Similarly, concepts like ‘desired state’ and ‘idempotence’ go back at least as far as mainframe and server automation. Similar concepts apply to cloud computing and DevOps too. In both, it is critical that automation routines are aware – of their own state and of the surrounding environment – so that they can test for and accommodate unexpected conditions, and still deliver the expected results.

    Given the depth of history in automation, and the many parallels with modern computing, some may claim that cloud is nothing new, that we have been doing that since the mainframe; while others will say something similar about DevOps. I think they are wrong, but there are definitely parallels, and George Santayana has a point – we should be at least informed by history, if we are going to try to write the future, while avoiding the mistakes of the past.

  • DevOps developers; don’t be a DevGoof

    DevOps developers; don’t be a DevGoof

    There was a lot of brush back last week over Jeff Knupp’s post about how DevOps is killing the developer. Frankly I wasn’t shocked by Knupp’s opinion that developers “are the dentists in the dental office”. In my 30+ years of involvement in the IT industry my experience is that developers often think of themselves as the only smart person in the room. Often times that is the reason they are are the only person in the room, lol. The fact is many developers relate better to code than to people. For me all this talk about DevOps killing the developer is akin to saying power steering killed the driver. Just because you can do more with new technology, does not mean one dies, one just has to pivot and in this case become business social.

    Now the sociable part may be the problem. Sometimes I feel that DevOps is trying to create a love fest between Ops, Developers, QA, security and the rest of the IT stack. While they may not have to love each other, I do think they all need to be nice to each other as opposed to ignoring  or just going around each other, as was all too often done in the past. A common scenario I have seen for example is for developers to rollover Ops by stating this is mission critical for the business. These tactics will no longer work to let developers have their way.

    Developers need to realize they need to become a normal part of the business social structure. They will be required to talk and work with people, not throw tantrums when they don’t get their way. Left unchecked, certain developer personality types can sabotage your project, or worse, make themselves no fun to work with.  I am sure we have all met and unfortunately had to work with people like that. In my career, I’ve encountered virtually every personality type. In fact, I’ve also knowingly hired all of them. They know who they are; they are the developer that if challenged or worse accurately taken to task for lack of being part of the team; quit cause they can’t manage the confrontation, thus interpersonal stress. In the old days they would not come out of their house for weeks continually playing Leisure Suit Larry, if your not familiar with it Google it

    I remember one of my good friends telling me this story that sums this whole developer persona issue perfectly. This company, we will call DevGoof, was a well funded start up. Every quarter they held a meeting with all the employees to let them know how the company was doing. Most employees had some kind of equity play in the company, so everyone was incented and theoretically interested in company performance. Several quarterly meetings came and went and not one developer showed up. Eventually DevGoof management got concerned and called a mandatory meeting for all developers’.

    DevGoof management put out some pastries, juice and coffee for the brain trust. Then proceeded to tell them why these meetings were important to them and their fellow employees. Notably pointing out how it is not just about them but also about the rest of the DevGoof team. This meeting went on for about one hour and not one developer asked a question. So eventually this meeting was over and everyone went back to developing. The next morning,   about 50% of the developers quit and some in a not so professional fashion.

    The moral of this blog is the DevOps is going to force the development community to become more interpersonal within the business environment. This will lead to personal success within the new world of DevOps. The DevOps Developer/Engineer that can demonstrate leadership and compassion for team will be the one leading the DevOps way within the organization. Don’t be a Devgoof!

    If you would like say something; email parker@devops.com and don’t forget to comment here.

  • Microsoft bridges the gap between Azure and DevOps

    Microsoft bridges the gap between Azure and DevOps

    DevOps can be easy for a startup. Many of the concepts and principles of DevOps come quite naturally to a fresh company just getting started. It’s a different story, however, for large, established enterprises trying to wrap their arms around this DevOps thing. For IT admins working in Microsoft’s Azure cloud platform, though, things just got a lot easier thanks to the integration of Chef and Puppet Labs.

    Many organizations are heavily invested in the Microsoft ecosystem. IT teams and administrators are familiar with Windows domains, Active Directory, Hyper-V, and Azure. They know how to write scripts and leverage PowerShell to get things done, but they’re much less familiar with the core principles of DevOps, or common DevOps automation tools like Chef and Puppet Labs.

    One of the driving forces of DevOps is the ability—or perhaps necessity—to automate those tasks that can be automated so IT resources are freed up to focus on more important tasks. Deploying and configuring virtual servers and applications is necessary, but it can also be tedious, and it is a task that can be easily automated using DevOps tools.

    The arrangement also works the other way. Smaller companies that are already familiar with, and invested in DevOps may need to scale to a platform like Azure. They should be able to build on what they’ve started, and continue to use the tools they’re familiar with as the company migrates to Microsoft’s Azure.

    One of the main attractions of Microsoft Azure is the degree of flexibility, choice and control it gives customers. Microsoft Azure’s partnership with Puppet and Chef allows customers to choose from an array of existing technologies and communities to easily deploy, configure, automate and manage their VMs.

    According to a Microsoft spokesperson Puppet Labs and Chef complement and extend Microsoft technologies such as Resource Groups and PowerShell Desired State Configuration (DSC) to offer more options for customers to migrate existing or deploy new applications to the cloud. The partnership offers Microsoft the ability to support Linux and UNIX environments, and also alleviates the concerns that organizations already using Puppet or Chef will have about abandoning their investment. Now, they can continue to use their Puppet modules or Chef recipes in Azure.

    Luke Kanies, CEO of Puppet Labs believes the integration of Puppet Labs and Azure will help Microsoft IT admins by making it easier to deploy applications across any platform or cloud environment. Kanies explained in a press release, “Our goal is to help you automate the configuration and ongoing management of your machines and the software running on them, so you spend less of your time firefighting and running simple scripts across a thousand machines, and more time getting great software in front of your users.”

    I spoke with Kanies about the difference in dynamics between a small company and a large enterprise. He told me that in a small company it’s much easier to communicate and coordinate resources, and the cost of failure of any particular project is much lower. For a large, established enterprise, however, there is assumedly a large base of existing customers, and there is more fear and worry about possibly disrupting normal operations.

    I also had a chat with Ken Cheney, VP of business development for Chef. His philosophy mirrors a lot of what Kanies described. Cheney told me that emerging companies have the luxury of starting from ground zero with a clean slate. There aren’t yet any established processes to navigate. The challenge is trying to transform an organization with established processes, and a team of existing developers over to a DevOps mentality. Integrating DevOps into Azure helps organizations to meet that challenge.

    DevOps adds an element of speed and simplicity that makes it easier for larger enterprises to be more agile. Using tools like Puppet Labs and Chef enables IT admins to add speed as a core requirement for infrastructure projects without disrupting or conflicting with other requirements—like security and stability.

    Ultimately, the new alliance illustrates Microsoft’s commitment to empower Azure customers with the best-in-class configuration and automation tools by embracing the technologies, communities and ecosystems that developers know and love. Combining Azure with powerful and popular platforms like Chef and Puppet Labs bridges the gap between traditional IT and DevOps—enabling old school IT admins to embrace DevOps, and DevOps startups to mature and evolve into larger enterprises.

  • Nagios is not a monitoring strategy

    Nagios is not a monitoring strategy

    When I visit clients to talk about DevOps, I usually ask them what their monitoring strategy is. Too often, the answer I hear is “We use Nagios”. I think Nagios is a great tool, but it sure is not a strategy. Nagios does a good job of monitoring infrastructure. It will alert you when you are running out of disk, CPU, or memory. I call this reactive monitoring. In other words, Nagios is telling you that your resources are getting maxed out and you are about to have issues. Proactive monitoring focuses more on the behavior of the applications and attempts to detect when metrics are starting to stray away from their normal baseline numbers. Proactive monitoring alerts you that the system is starting to experience symptoms that can lead to a degradation of performance or capacity issues which is more preferable than Nagios telling you are about to be screwed. With reactive monitoring, it is not uncommon that customers start complaining about the same time that the Nagios alerts start going off. The goal of proactive monitoring is to head off issues so that customers don’t even notice.

    The next question I ask is “What things are you monitoring?”  A typical answer usually revolves around various infrastructure assets and databases. That’s a good start but there is much more to consider. But first, let’s talk about why proactive monitoring is so critical. In the pre-cloud days we used to ship software to our customers where they would install the software, perform capacity planning tasks, manage the infrastructure, and operate the day-to-day activities. Once we shipped the code we were done. In today’s world, we are no longer shipping product. Instead we are delivering services that are always on. The customer no longer owns and operates the infrastructure and the software. Instead they pay for a service and expect that service to run reliably all the time. To meet those expectations, we need a more robust monitoring strategy. We need to monitor more than just the infrastructure.

    A good monitoring strategy starts by identifying all of the actors who needs access to data and all of the categories of data that needs to be tracked. Some metrics are monitored in real-time while others are mined from log data. Every good monitoring strategy is accompanied with a sound logging solution. In order to perform analytics to predict trends within the data, one must collect various data points ranging from customer usage activity, security controls, deployment activities, and much more. The following presentation goes into much more detail about the different areas that should be monitored and why different actors need these data points to perform their jobs.

    [slideshare id=33320431&doc=monitoringstrategies-0408014v1-140409081614-phpapp01]


    The bottom line is, before building in the cloud, it pays to invest some time into a sound monitoring strategy. I have seen too often where teams don’t think through how to support these highly distributed, always on SaaS solutions and end up delivering software that does not meet the reliability and quality expectations of  customers. Monitoring provides feedback to developers, product owners, operators, and even customers so that systems can continuously be improved. Nagios is great, but there is no single monitoring solution that can implemented to effectively operate today’s always on services.

  • Don’t Let the (April Fools Day) Joke Be on You

    Don’t Let the (April Fools Day) Joke Be on You

    As much as seasonal increases in demand for on-line resources are discussed, the one day that’s often overlooked is April Fools Day.

    It’s the day the Internet loses its mind and your best bet is take everything not just with a grain of salt, but with the entire shaker.

    The use of April Fools’ Day to promote brand awareness and bring some laughter into the world as everyone tries to outdo everyone else in a bid to be named the King of Fools is well known. This is no more a surprise today than is Black Friday, Cyber Monday or Super Bowl Sunday.

    So it behooves those participating in the tom foolery to be prepared. That means being ready to handle an increased demand for whatever it is you’re offering up for consumption. This is where devops shines; where automation and orchestration and a demand-driven scalability strategy is your best answer. Because you can’t be sure your offering is going to go viral, but you can be sure it won’t if any piece of the application delivery chain breaks under the pressure.

    In other words, this is unacceptable:

    err-db-conn

    What might have gone viral may end up languishing as just another overlooked and forgotten attempt because of a lack of database resources and a failed scaling strategy.

    One of the key aspects of devops is that it should approach scalability with a comprehensive view of how each piece of the delivery chain needs to scale – and when. Thresholds and metrics collected from each domain of an application architecture must be correlated and understood in the context of how it impacts capacity so that it can be automatically scaled – or at least addressed – on demand.

    Maybe that means devops must advise a cloud-based approach to handling demand for such days. Maybe that means a bit more preparation and integration across the entire application delivery chain to ensure the load balancing service is basing its decisions on the right variables such that resources are maximized and enable greater scale across the application. Maybe that means throwing up a cache to reduce the pressure on web and application servers, or taking advantage of a CDN.

    Regardless of the approach to how you’re going to scale, devops practitioners should be driving the process to ensure that on April Fools Day – or any well-known high demand generation day – the joke is not on them.

  • The Automation Continuum

    The Automation Continuum

    The speed of innovation these days is often influenced by the speed of adoption of new and exciting tools, and specifically open source tools.  Open source projects have been growing at an exponential speed over the course of the past few years; however the process for exploring, testing, configuring, and ultimately integrating these in production often times is still quite complex and time consuming.  In many cases, this process is still done manually.  Like with all DevOps processes by automating this, we are then able to adopt new tooling much more quickly, and with less human error in the process.

    The Open Source Revolution

     

    The friction in this process is due, in large part, to the fact that each of these stages from exploration through POC and testing, integration and then management, many times requires the use of very different tools for each stage, on top of a completely different setup and environment.  This means that every time you want to move from exploration to testing, for example, you have to basically rebuild the entire system.  This can become quite frustrating and, as mentioned above, time consuming.

    What if we could streamline this process  and explore tens and even hundreds of projects quickly, thereby enabling us to seamlessly increase our innovation?

    How this could work – the flow:

    1. Exploration: Explore the product without having to install any software at all.  This could be through a click of a button on Github, and seeing the product in action.  This would enable you to play with it without having to download, configure, or set up any machines.

    2. Testing: When we move to trying it out, we want to use the same model as in the exploration phase.  We’d like to try it out also on a SaaS basis, but this time with more control.  By this I mean testing with real clusters & machines, in a more high performance, and production-like environment.

    3. Development: At this stage, we want to be able to test it with our actual stack, and plug it into our project quickly.  Then, eventually at a later stage download it and run it in our own environment.

    What’s Needed

    With a unified tool for all of these stages, the majority of the friction in the process can be diminished.  One way to achieve this is by running the project as a service or in our environment, with an orchestration engine that can basically be used to take us through all these stages.

    By wrapping the entire project into an uber-launcher [which with Cloudify we call it “the widget”] that any open source project can plug into – like an app store or repository, and any user can start using immediately without necessarily having to know how exactly it runs or works.

    The nice thing is that we can eventually take the software from that app catalog or store, since it’s not packaged as a black box but rather as a blueprint or script. We can then fork it and customize it to our needs.  Because of this, we can actually use the same tools through the entire cycle and break the friction completely.

    So what it all boils down to, is the basic principle of combining the power of SaaS and cloud orchestration to avoid complexity of installation, use a script-based model to make the packaging of software generic – but still customizable, and use a cloud abstraction to move environments without having to change recipe.  This is what we call the automation continuum, and we’ve been using to demonstrate how to take the power of any open source project to any cloud.

  • It’s the Outbound Stupid!

    It’s the Outbound Stupid!

    As nice as the word “Egress” may sound, I like “Outbound” better. Outbound is hardcore firewalling for the traffic that was initiated on the “trusted” side of the firewall, and is destined OUT to the unknown. However, over the last 20 years network administrators have put much more emphasis on what can come IN to their networks, rather than to worry about what comes OUT of them. There are many reasons for that, but the key one is that if nothing can come in, then we need not worry about what comes out. Right? Yea, right…
    Fast Forward 2014 we have firewalls everywhere. On our smartphones, laptops and home broadband wifi routers. In the cloud, any typical IaaS setup has a firewall for every group of instances, usually called Security Group and every instance has its own, internal firewall that is controlled by the instance OS. We are starting to see more and more people that use them as a core building block, in a  network security architecture, and as a fundamental element of it. But as most of you (us) actually spend time, energy and concern about inbound firewall rules, only 15% of you (us) even bother with the Outbound. That’s true, and its about time we change that.

    Plan. Plan for Success.

    A well planned inbound firewall policy can give the bad guys a true challenge, but what happens when they do get in and there’s no outbound policy in place? Its an all-you-can-eat buffet. With a well planned Outbound policy, theres a strong chance they will go away, or be easily discovered – and that’s a great ROI for your time!
    It all starts with a written (English, not Erlang or Java) security policy that outlines the way groups of servers interact with each other and with the outside world. First for the inbound/ingress which should be pretty easy to formulate. Then comes the outbound/egress tricky part – lets take a closer look at an application server.
    Usually application servers sits in one of the middle tier, trusting traffic coming from the web-tier and initiating requests to the database tier before sending the replies back to the web servers.
    Inbound: Allow traffic from Web Servers, usually only for HTTP or HTTPS depending on the Web<>APP settings.
    Outbound: Allow DB traffic to the Databases on the specific DB port, for example, TCP3306 for MySQL.

    Don’t forget the monitoring

    Any monitoring solution you may be using, affects your security policy. An agent-based monitoring solution installed on the machine will have to be allowed to connect out, where an external monitoring service, that probes your servers from the outside, will have to be allowed in to do its job.
    Agent Based Monitoring: Allow Outbound on specific protocol to a specific IP or a list of IPs
    External Monitoring: Allow Inbound for specific protocol and from a specific IP or list of IPs

    What else on the Outbound? The Killer (No) Rules

    Our app server runs Ubuntu so it may needs access to the ubuntu update services and also needs DNS to live happily. Now the common theme would be to allow access to update services for outbound on https (TCP443) and to allow outbound DNS (UDP53). Right? WRONG. Why not limit only to the specific repository services that our OS needs? The hardline DevOps will kill updates altogether, stating that any part of your application should not update itself. You can always bake/launch a fresh updated one instead of messing with a working instance.
    Result: No Outbound HTTPS TCP443
    Now for DNS. If you are a security concerned it is recommended to stop using DNS altogether and use /etc/hosts instead. A less drastic approach would be to allow DNS access only to a DNS server that you trust (E.g. Google’s 8.8.8.8), this is done to make sure that data leaked using DNS queries could only reach Google, and they already know everything.
    Result: No Outbound DNS  UDP53 or Allow DNS (UDP53) to 8.8.8.8 if you must.

    Your Feedback Loop: The Network Logs

    After setting this strict Outbound policy, we can finally identify the services that were left hanging, as we just severed their lifeline. It could be a non-critical agent that we should uninstall, or, god forbid, a rogue piece of code some bad guy wrote and now can’t connect to its C&C server – more on that next time.

    Happy Firewalling,
    Zohar

  • Red Hat Announces Certification for Containerized Applications, Extends Customer Confidence and Trust to the Cloud

    Red Hat Container Certification delivers secure, consistent and simplified platform for ISVs to take advantage of containers in Docker format

    RALEIGH, N.C., Mar 11, 2014 (BUSINESS WIRE) — Red Hat, Inc. RHT -0.84% , the world’s leading provider of open source solutions, today announced the extension of its application certification program to include containerized applications. The Red Hat Container Certification ensures that application containers built using Red Hat Enterprise Linux will operate seamlessly across certified container hosts. Designed with the needs of independent software vendors (ISVs), service providers and their enterprise customers in mind, the certification extends the confidence customers have with Red Hat Enterprise Linux, which currently supports thousands of certified applications, to certified containers running on certified container hosts. The pending release of Red Hat Enterprise Linux 7 and Red Hat’s OpenShift Platform-as-a-Service (PaaS) offering will both be certified container hosts, with Docker as a primary supported container format.

    Linux Containers

    Linux Containers have emerged as a key open source application packaging and delivery technology, combining lightweight application isolation with the flexibility of image-based deployment methods. Developers have rapidly embraced Linux Containers because they simplify and accelerate application deployment, while many PaaS platforms are built around Linux container technology, including OpenShift by Red Hat. Red Hat Enterprise Linux implements Linux Containers using core technologies such as Control Groups (cGroups), Resource Management, SELinux, and network namespaces, enabling secure multi-tenancy and reducing the potential for security exploits.

    Building on the capabilities of Red Hat Enterprise Linux, application containers are deployed as software packages that include the application and all of its required runtime components. Benefits include:

    • Instant portability , deploy the certified application container across any certified container host
    • Minimal footprint , avoid the overhead of virtual machine images which include a complete operating system
    • Simplified maintenance , reduce the effort and risk by patching applications along with all of their dependencies
    • Lowered development costs , develop, test and certify applications against a single runtime environment

    Red Hat Container Certification

    The Red Hat Container Certification is the latest addition to Red Hat’s industry-leading certification portfolio that includes Red Hat Enterprise Linux and Red Hat Enterprise Linux OpenStack Platform. The certification is also part of a larger set of Red Hat technology initiatives which in turn support thousands of third party technology partners within Red Hat’s global ecosystem

    To support this newly announced container certification, Red Hat is also announcing the container certification Partner Early Access Program (PEAP). The PEAP will run through late spring and provide the ability for ecosystem partners to participate in early testing, integration and feedback of the tools and resources required for containerization prior to the official launch of the certification and partner program, currently planned for mid-2014. Beginning today, companies interested in being part of the PEAP can learn more by visiting https://engage.redhat.com/content/enterprise-early-access-se-201402101640.

    Supporting Quotes

    Paul Cormier, president, Products and Technologies, Red Hat

    “Twelve years ago, Red Hat shook up the enterprise status quo with the introduction of Red Hat Enterprise Linux, a safe, consistent Linux platform for the ISV ecosystem. Today, the trust that ISVs place in Red Hat Enterprise Linux can extend to containerized applications with the Red Hat Container Certification, ensuring that containers built on Red Hat Enterprise Linux will work as intended across certified hosts, delivering expanded application flexibility, lowered costs and simplified maintenance, all backed by the support and expertise expected from Red Hat.”

    Ben Golub, CEO, Docker

    “As the de facto standard in open source container technology, we are pleased to see Red Hat embracing the container movement as a means of application efficiency and consistency across computing footprints. By offering a container certification on Red Hat Enterprise Linux and Docker, Red Hat is providing the industry’s only standardized, stable platform for commercial container workloads, providing a safe, reliable way to deliver the enterprise applications of the future.”

    Matt Asay, Vice President of Marketing and Business Development, MongoDB

    “Consistent with its mission of high value and affordability, Red Hat continues this trend through a supported platform that enables consistent enterprise-grade application deployment. We’re excited to work with Red Hat to provide customers a seamless database environment that is consistent from development to deployment, regardless of where it resides within the open hybrid cloud.”

    Connect with Red Hat

    About Red Hat, Inc.

    Red Hat is the world’s leading provider of open source software solutions, using a community-powered approach to reliable and high-performing cloud, Linux, middleware, storage and virtualization technologies. Red Hat also offers award-winning support, training, and consulting services. As the connective hub in a global network of enterprises, partners, and open source communities, Red Hat helps create relevant, innovative technologies that liberate resources for growth and prepare customers for the future of IT. Learn more at http://www.redhat.com .

    Forward-Looking Statements

    Certain statements contained in this press release may constitute “forward-looking statements” within the meaning of the Private Securities Litigation Reform Act of 1995. Forward-looking statements provide current expectations of future events based on certain assumptions and include any statement that does not directly relate to any historical or current fact. Actual results may differ materially from those indicated by such forward-looking statements as a result of various important factors, including: risks related to delays or reductions in information technology spending; the effects of industry consolidation; the ability of the Company to compete effectively; the integration of acquisitions and the ability to market successfully acquired technologies and products; uncertainty and adverse results in litigation and related settlements; the inability to adequately protect Company intellectual property and the potential for infringement or breach of license claims of or relating to third party intellectual property; the ability to deliver and stimulate demand for new products and technological innovations on a timely basis; risks related to data and information security vulnerabilities; ineffective management of, and control over, the Company’s growth and international operations; fluctuations in exchange rates; and changes in and a dependence on key personnel, as well as other factors contained in our most recent Quarterly Report on Form 10-Q (copies of which may be accessed through the Securities and Exchange Commission’s website at http://www.sec.gov ), including those found therein under the captions “Risk Factors” and “Management’s Discussion and Analysis of Financial Condition and Results of Operations.” In addition to these factors, actual future performance, outcomes, and results may differ materially because of more general factors including (without limitation) general industry and market conditions and growth rates, economic and political conditions, governmental and public policy changes and the impact of natural disasters such as earthquakes and floods. The forward-looking statements included in this press release represent the Company’s views as of the date of this press release and these views could change. However, while the Company may elect to update these forward-looking statements at some point in the future, the Company specifically disclaims any obligation to do so. These forward-looking statements should not be relied upon as representing the Company’s views as of any date subsequent to the date of this press release.

    Red Hat, Red Hat Enterprise Linux and the Shadowman logo are trademarks of Red Hat, Inc., registered in the U.S. and other countries.Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

    SOURCE: Red Hat, Inc.

    Red Hat, Inc.John Terrill, 571-421-8132 jterrill@redhat.com

    Copyright Business Wire 2014

  • JumpCloud Joins Rackspace Marketplace

    Automating Server Management is Now Just a Click Away For Rackspace Customers

     BOULDER, Colo., Feb 25, 2014 (BUSINESS WIRE) —JumpCloud™ , the leading automated server management tool for DevOps and IT pros, today announced that its best-in-class service is now available through the Marketplace for Rackspace® Hosting,RAX +5.66% , the open cloud company. An ideal addition to the Marketplace, JumpCloud automates the tedious tasks of managing servers so DevOps and IT pros can focus on what makes their businesses tick: innovation.

    Rackspace customers can now receive automated server management capabilities with JumpCloud. This bolsters the shared goal of supporting highly agile and flexible infrastructures and workflows. With JumpCloud, end users are able to easily and effectively automate the management of their Rackspace servers, which saves time while also securing their infrastructure. The JumpCloud platform effectively automates tasks such as SSH/privileged user management, admin activity monitoring, patch detection and selected compliance requirements.

    “As one of the industry’s leading IaaS providers, Rackspace is in a unique position to complement our offering,” said Rajat Bhargava, President and CEO of JumpCloud. “Server management is critical, and every time someone spins up a dedicated server or cloud server based on OpenStack at Rackspace, we can now be a natural extension; we will be there to help automate the labor intensive, yet essential tasks associated with managing servers – in the cloud or otherwise.”

    “As organizations have increasingly scaled their server infrastructures, many have found it challenging to realize the full potential of both enhanced organizational speed and agility,” said John Engates, Rackspace CTO. “Rackspace solves this problem for organizations by offering a unique hybrid cloud platform, which combines public and private cloud form factors with dedicated, bare metal servers. The addition of JumpCloud to the Marketplace will help customers effectively leverage the full potential of the infrastructure they host with Rackspace.”

    For additional information about JumpCloud and the Rackspace Marketplace, visit:https://cloudtools.rackspace.com/apps/1007?restoreSearch=true#!overview .

    About JumpCloud

    JumpCloud automates manual, tedious server-management tasks from the cloud for DevOps and IT pros. Complementary to and integrated with Chef and Puppet, JumpCloud picks up where they leave off by automating management of users, patches, security, and compliance. JumpCloud returns days to DevOps and IT admins’ lives while increasing security. An automated SaaS-based offering, JumpCloud installs in seconds and deploys on physical, virtual, or cloud servers. For more information visit JumpCloud.com.

    SOURCE: JumpCloud

    Matter Communications for JumpCloudMaria Brown / Ryan Lilly, 978-499-9250jumpcloud@matternow.com

    Copyright Business Wire 2014