text:
urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bb Enterprise DevOps DevOps is a movement, rooted in the agile community, to improve the collaboration between the development and operations teams, speeding software delivery and improving quality. While the DevOps has traditionally focused on "born on web" companies, IBM' 0 30 11 2014-12-04T04:27:33-05:00 IBM Connections - Blogs urn:lsid:ibm.com:blogs:entry-4f61dee3-34ef-49a7-a158-8b706a828a92 Adapting to the Pace of Business with DevOps mdelder 120000CYNE active false mdelder 120000CYNE active false Entradas de Comentários Curtir true 2013-05-03T15:49:29-04:00 2013-05-03T15:49:29-04:00

 Last week, Opscode hosted ChefConf, a 4 day event focused on adopters and contributors of Chef. IBM was a Gold sponsor of the event, and several of my colleagues and I had the wonderful opportunity to attend. While there, IBM presented a keynote talk on how we're adopting Chef as part of our IBM SmartCloud strategy, as well as a more detailed breakout session and kiosk in the exhibition hall.

 ChefConf demonstrated the electricity of how DevOps and Continuous Delivery are shaping the future of how businesses compete in the market place. While many great keynotes were given at ChefConf (including Disney, Nordstrom, Facebook, and Jamie Winsor's (@resetexistence) great talk on Berkshelf), I thought that Adam Jacob's (@adamhjk) keynote really summarized why this trend -- although enabled by technology -- is really driven by the needs of the business.

 Adam opened his talk with a discussion of the impact of globalization. In the first phase of globalization, standardization of how we move goods through container-based shipping took about 40 years to take over a majority of goods (minus oil and grain) between countries. The internet achieved similar penetration in about half that time (22 years). As the goods and services become even more dependent on the internet and mobile platforms, new business models emerged and existing business models were forced to adapt. For instance, Adam cited the impact of customer service to the early success of Walmart and how Amazon focused on the same aspect of customer service and volume pricing, but with the application of technology to improve the consumer experience. He also cited an example of a traditional business adapting through his recent experience with Allstate. When he needed to file an insurance claim -- his claim was serviced through his smart phone. He even described an innovative business model to improve how bananas can be brought to market using mobile phones! (Ubernana, which may officially be Trademarked by Adam :).

 In each example, he demonstrated that "software is the interface for consumption." In other words, software is the critical fabric that enables businesses to engage and convert users into customers.

 In order to adapt to these business requirements, he stressed the need to break with traditional heavy-oversight driven process and focus instead on empowering the doers and focusing on accountability. We have to change our organizations from a focus just on high level design and more focus on the "full stack engineer" that understands the holistic view of the delivery process and who is empowered to make changes and optimize the delivery process over time.

 Ultimately, Adam believes that the economic impact of what we're doing with DevOps will move much faster than the first phases of globalization. Even more intriguing, he asserted that when we're done with the transformation, we won't look the same at all. Business will change in the structures and roles of the organization to adapt to how quickly we must deliver capabilities in order to meet the needs of our users.

 Perhaps most succinct, he said that "DevOps isn't about us, it's about a set of ubiquitous global trends that require new behavior to survive the next few decades in the global economy."

 Regardless of whether you agree or disagree with Adam's position, we can all agree that it's going to be an exciting transformation and journey together!

 *Image was part of Adam's talk and was reused from http://www.flickr.com/photos/dkeats/4128747046/sizes/s/in/photostream/
 Last week, Opscode hosted ChefConf, a 4 day event focused on adopters and contributors of Chef. IBM was a Gold sponsor of the event, and several of my colleagues and I had the wonderful opportunity to attend. While there, IBM presented a keynote talk on how... 0 0 4075 urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bb Enterprise DevOps 2014-12-04T04:27:33-05:00 urn:lsid:ibm.com:blogs:entry-4abfa8e3-7776-44f1-9838-fa7678498875 Wait Makes Waste CindyVanEpps 120000EA06 active false Entradas de Comentários Curtir true 2013-01-24T13:43:59-05:00 2013-01-24T13:43:59-05:00 "You'll eat it and you'll like it!" my Grandma Stowell used to say. Its not that she was a food tyrant but rather that she had spent all day in the kitchen preparing a meal.

Now I can go to a restaurant, place an order and be served within 20 minutes or so. The testing and feedback on the product I receive happens immediately. If I determine that it is so delicious I must have more, or that I have capacity for dessert (as if dessert has any pre-conditions!), I can receive more product in the same dining event.

Through streamlined processes and technology, I can drive up to a window, place a food order, and receive it within minutes. Usually I get exactly what I want and am happily on my way. But on the rare occasion something goes awry – for instance, if I protest the size or warmth of my chicken nuggets; I can get my order replaced in under 30 seconds while I wait.

Whether I am at a fast food restaurant or a diner, I don't really care if the preparers are the same as the servers. I really care that I get my requirements met quickly and that the product is acceptable quality. If I need to adjust the order based on missed expectations, I expect to do that also in an acceptable time frame.

DevOps is the PrepServe of software delivery.

The old adage "haste makes waste" is based on the principle that making a mistake requires a costly return to the beginning of the work because of loss of large blocks of time required to accomplish the work and the loss of resources wasted in starting over.

Consider how technology has advanced the software delivery world. We have the ability to collaborate to specify and understand requirements, even with time zone challenges, in days rather than months. Delivering in smaller increments of capabilities not only gets capability in the hands of the users faster (the pot o' gold of agile methods) and it also greatly reduces the time it takes to isolate the cause of a defect. Automated testing ensures that tests can be run more often and test results are collated and reported in hours and minutes rather than days and weeks. Virtualized services reduce the cost of complex test environments from millions of dollars down to hundreds. Capturing infrastructure as code ensures that development and test environments are "production-like" to reduce the risk of error resulting from environment inconsistencies.

With software delivery, wait makes waste. In the time it takes to develop a large system, the players change. The business analyst who is assigned to user acceptance test your product 1 year after someone else specified the business requirements likely will not understand the original intent. Technology changes: the architectural constraints as well as the business analysts' technology frame of reference that impacted the original requirements are likely far different. Business drivers change: competitors advance their products and approaches. Resources change: this year's budget cycle may not provide the developers, enablement program, or infrastructure that your large system change requires.

A most poignant example of wait makes waste happened when I worked in software development for Space Shuttle Mission Control at Johnson Space Center, NASA. We were collecting the requirements to procure the first set of distributed systems' hardware to start migrating Space Shuttle Flight Design off the mainframe. In order to ensure a low cost solution, the NASA executive sponsor explicitly captured the requirement that the monitors in the new system would be black and white displays. At the time, color monitors were bleeding edge technology. During the many months of the request, bid, and award to vendor process, the chosen vendor had advanced their technology so that color monitors were their primary product. We actually paid the vendor to downgrade the capability in their primary product to meet the specific requirement! Needless to say, I was disappointed both as a system user and as a tax payer.

"You'll eat it and you'll like it!"

It is an extreme example, but certainly represents the paradigm for delivery of business value in software that many business users have come to expect as their reality: belabored and detailed processes that in the name of "haste makes waste" cannot be streamlined. I provide the food acquisition examples to encourage that there is a better way. DevOps provides fast service and an immediate feedback loop but those are really the means to the end – customer satisfaction. And for business users dependent on software systems, their satisfaction is delivered as functionally appropriate, secure, available, responsive and easy-to-use systems. Can you biggie size that for me, please?

 "You'll eat it and you'll like it!" my Grandma Stowell used to say. Its not that she was a food tyrant but rather that she had spent all day in the kitchen preparing a meal. Now I can go to a restaurant, place an order and be served within 20 minutes or so. ... 1 0 3788 urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bb Enterprise DevOps 2014-12-04T04:27:33-05:00 urn:lsid:ibm.com:blogs:entry-39413631-8a62-43a9-b45a-99ae10b6384f Making Your Automated Tests Faster ann_marie_99 06000073UA active false Entradas de Comentários Curtir true 2012-11-06T17:14:18-05:00 2012-11-14T09:11:26-05:00
One part of my job is helping other teams adopt DevOps in general, and continuous delivery in particular. But I have a problem: many of them have a suite of automated tests that run slowly; so slowly that they only run a build, and the tests that run in the build, about once per day. (Automated test run times of 8-24 hours are not uncommon.) There are several reasons why this is the case, including:

The artifacts that are produced from the build, and then copied over to the test servers, are very large (greater than 1 GB in size). Also, sometimes the artifacts are copied across continents.

Sometimes there are multiple versions of the build artifacts that must be copied to different test servers after the build. A typical product I deal with will support at least a dozen platforms; a few support around 100 different platforms, when you multiply the number of supported operating system versions times the number of different components (client, server, gateway, etc.) times 2 (for 32- and 64-bit hardware).

Often, the database(s) for the product must be loaded with a large amount of test data, which can take a long time to copy and load.

Many products have separate test teams writing test automation. Testers who are not developers tend to write tests that run through the UI, and those tests are usually slower than developers' code-level unit tests.

Running builds and tests often, so developers know when they make a change that breaks something else, is a key goal of both continuous integration and continuous delivery. Ideally, a developer should get feedback on whether their code is "ok", using a quick personal build and test run, within 5 minutes. Anything over 10 minutes is definitely too slow; the developer will probably move on to something else, make more changes, and forget exactly what was changed for that particular test.

Once the quick tests pass, the developer can run a full set of tests and then integrate the tested changes. Or, in cases where a full set of tests is extremely slow, the developer can integrate his or her code changes once the quick tests pass, and then let the daily build run the full set of tests.

I proposed a DevOps Days open space session on this topic at DevOps Days Rome 2012. We brainstormed ways to make automated tests run more quickly. We focused more on quick builds for personal tests, but most of these ideas would make the full set of tests faster too. Many thanks to the dozens of smart people who contributed their ideas. I don't even have their names, but they know who they are. I'm sure we'll use several of these ideas right away.

Fail quickly

Often, tests are run in a silly order - alphabetically, for example, or in the order that they were created. We can be much smarter about the order in which we run our tests.

Run a quick smoke test first

Run a quick smoke test to make sure that the infrastructure and services your tests will need are available. Can you ping the servers you need, connect to your databases, etc.? Ideally, this should only take a few seconds to a minute. If some critical part of the infrastructure is missing, there's no reason to waste time setting up the rest of the tests.

By the way, running smoke tests often on your production servers is a good idea too.

Run a small set of tests that fail often next

With experience, it's easy enough to identify a small set of tests that seem to fail more often than the others. Run those next. Ideally, this should only take a few minutes. If this takes more than 5 minutes, reduce the number of tests in this bucket.

Run tests that never fail later

If you have tests that are on code that has not changed in a long time, and the tests never fail, you can run them near the end of the series of tests.

Run slow tests last, or not at all

Run the slowest test buckets last, as long as earlier tests don't depend on them.

By the way, as a side note - ideally you would run your tests in a different order now and then. Sometimes a test won't fail unless it's done in the wrong (or is that the right) order.

Run in parallel

Run test buckets in parallel

Sad but true - often, tests are run sequentially. Look for ways to run many tests in parallel, even if it means deploying many VMs to do the testing. When you can deploy many VMs cheaply and automatically, then you should take advantage of that to make the testing faster.

Use snapshots of databases or VMs to make it easier to run tests in parallel

You can configure VMs more quickly if the saved snapshot/image that you start with is close to the final system that you need. There's an art to putting enough of your configuration into the VM images to make your deployment fast, without getting into a state where you have far too many VM images to manage.

You can also create database backups with a lot of your test data pre-loaded, rather than relying on SQL statements or running code to populate the database. In some cases you may be able to leave a database (or several databases) up and running, and reuse the same data over and over again. In other cases you may be able to have a pool of databases that are ready for testing, assign one database from the pool to a test suite, and then revert the database to its original state after the test suite has executed.

Break up tests into smaller groups

Divide your application into components, and test the changed components

Most software can be divided into logically separated components, with clearly defined interfaces with and dependencies on other components. Once you do that, you can build and test the components separately before testing them together. If you only have to re-test your own component in personal builds, you won't have to wait as long for results.

Automatically determine which tests to run when code changes

There are some very snazzy systems out there which can automatically decide what tests to run, based on the code that was changed. This is a topic that's too broad for this blog post.

Save time on I/O

Mock responses

Instead of contacting actual external services, in personal builds you can mock the services you're not trying to test. For example, you can record the expected response to each request, and play that back. This saves you the time spent in the request/response round trip, and if you are doing many round trips in your tests, that time can add up. There are many open source and commercial tools available to help with this. Green Hat is a great service simulation tool what was recently acquired by IBM.

Use LXC (Linux Containers)

Sometimes you don't need to set up a new virtual machine for testing. LXC may be enough, and it's faster.

Move servers and data so they are close to one another

If you have to copy data across networks, or even across continents, take a long hard look and see if there's a way to avoid it. Even if this means spending money on hardware, software, and setup, it might be worth it.

Make your test infrastructure faster

This seems obvious, but sometimes we forget this option. Use faster hardware, or faster VMs. Do performance tuning on your test infrastructure, including the systems, storage, networks, and so on. For example, some companies use BitTorrent to transfer large files much more quickly.

Cache what you can

This is going to depend on your specific application, but you should cache what you can, without making your tests less useful or less accurate.

See also: Use snapshots of databases or VMs to make it easier to run tests in parallel

Look in the "Run in Parallel" section above. This also saves time on I/O.

Remove some tests

Remove slow tests

Set a maximum run time for each test, and enforce it. If an individual test takes a long time to run, it will slow down everything and everyone else. If a test is too slow, you can improve the test itself to make it faster. Or, it may be that the performance of that part of your application is too slow, in which case you should fix the performance of the application.

People have different ideas on how to enforce this. Some companies created a report of the slowest tests each day or week, and told people to fix them. Others put a timer on each test and automatically made the test fail after a certain amount of time. The idea is that the people writing the tests should feel the pain when their tests are too slow.

Replace some UI tests with code-level tests

If a UI test is slow, and you can test the same thing by testing the API without the UI, then it's usually faster to replace the UI test with an API test.

Replace some tests with monitoring

In some cases, it may be OK to release code that is not fully tested and rely on monitoring to catch any problems. In reality, no code is 100% tested. It's just a question of how much testing you need for your specific business environment.

A few people also suggested that your running components can report their health back to a monitoring server on a regular basis.

Note that it's easier for monitoring to help you find where and when problems were introduced if you have "deployment lines" in your metrics -- markers showing when changes were made, with a link to what those changes were.

Conclusion

I hope you've gleaned a few useful ideas from this article. If you have more to add, please contribute them to the comments section below. Thank you!

 One part of my job is helping other teams adopt DevOps in general, and continuous delivery in particular. But I have a problem: many of them have a suite of automated tests that run slowly; so slowly that they only run a build, and the tests that run in the... 4 0 8722 urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bb Enterprise DevOps 2014-12-04T04:27:33-05:00 urn:lsid:ibm.com:blogs:entry-416597f0-2618-4a1f-90c1-8218e6dc06d5 Who moved my cheese? - An exploration of the effect DevOps has on roles in the enterprise DanBerg 0600006G7X active false Entradas de Comentários Curtir true 2012-09-07T09:26:12-04:00 2012-09-07T16:01:57-04:00

 Everyone is painfully aware that as technologies improve and evolve it becomes harder to deliver new features with quality to demanding customers. With new social and mobile applications customers have become trained to having their requests fulfilled within days and weeks versus the more traditional months and even years that we have seen in the past. So as many folks have done you have turned towards DevOps as the savior to help you deliver features faster. However to really adopt DevOps, one needs to introduce tools that promote good behaviors but you also need to make necessary cultural changes.

 With the introduction of DevOps into an organization it is not unlike Sniff, Scurry, Hem and Haw having their cheese (success and happiness) moved within the maze of life in the great book Who Moved My Cheese? by Dr. Spencer Johnson. Before the introduction of DevOps within an IT organization, teams were content with slow processes which ensured quality but reduced the organization's ability to be lean and agile. The operations team has full control over all IT processes and changes to environments. They rely on older automation technologies (or manual processes) with little to no management of the changes. Folks were content during these times. It may be slow but no one cared that much as long as the work was done. This is the time in the book when Hem and Haw became content and arrogant because they had a seemingly endless supply of cheese.

 Then the world began to change...

 The cheese was moved...DevOps principles and tools were adopted.

 Now Hem is annoyed, "Who moved my cheese?" The introduction of DevOps principles and tools has changed the game for how changes to environments are defined, managed, and delivered. Thus roles within the organization will need to change and/or emerge to deal with DevOps.

 We are going to focus on four roles and the changes we are seeing due to DevOps.

Release Engineer

Application Developer

Infrastructure Specialist

(new) Infrastructure Developer

Before we jump into each role I wanted to call out two quotes that I believe are appropriate here. First, a quote from Haw that he chiseled on a wall within the maze:

If You Do Not Change, You Can Become Extinct

The second quote that I really like is the definition of Insanity by Albert Einstein.

Insanity is doing the same thing over and over again and expecting different results.

Release Engineer
 Generally a Release Engineer is concerned with the compilation, assembly, and delivery of software components. Often the role is responsible with defining and managing the Release Plan, which includes the streams and iterations for the release. When folks talk about a Release Engineer they almost immediately think of the person that is responsible for setting up the build process to build the software components.

 With DevOps we are seeing that the role of the Release Engineer is expanding to include the delivery process as well as the build. With new tools such as IBM SmartCloud Continuous Delivery, a Release Engineer is responsible for owning and automating the release process to build, package, deploy, and test software changes. The Release Engineer does not work in a vacuum. She must work with architects across the organization (e.g., Application, Operations, Test, etc.) to define which components are involved in a release, what test environments will be required for testing, what standard cloud patterns need to be used for testing, etc. The Release Engineer is the goto person for release process and is responsible for encoding (automating) the release process using DevOps inspired lifecycle process tools.

Application Developer

 Everyone knows that the Application Developer is responsible for software development that involves the development of application code that will be built into software components. Application Developers are generally multi-lingual which is to say they are skilled in the development of multiple languages (e.g., Java, .Net, Ruby, etc.) and most developers today have some understanding of Agile development principles. These principles include iterative planning and development, test-driven development, module software components, self-documenting code, etc. A problem with many Application Developers is that they have little to no understanding of the operational environment that their code will be deployed which dramatically increases the potential for problems due to invalid assumptions and/or down right ignorance.

 With DevOps the changes to the Application Developer role vary across organizations. Based on my observations the Application Developer continues to be primarily responsible for the coding and delivery of software components, but the developer cannot work in a vacuum. First the architecture of the application must be defined, readily accessible, and easily understood by everyone on the team (developers, testers, release engineer, operator, etc.). You don't need to have formal UML training to document your application architecture (but it doesn't hurt). Even creating a sketch of the architecture that is accessible to everyone would be a great first step. The importance of documenting the architecture is to understand the key components to be deployed and to document the assumptions the components make on the environment. This will help to drive development in the correct direction and avoid costly architectural mistakes that are not caught until late in the release. As you look towards tools, keep your eyes open for tools that allow you to document the architecture directly within code that is ultimately executed by programs to setup and configure environments (note we are exploring options in our SCCD project).

 A second change in the Application Developer role is expanding his knowledge of the operational environment. Granted you will always have specialized developers that live in a vacuum but these will be few and far between moving forward. With DevOps it becomes much more important that Application Developers become operationally aware as they take on more responsibility for the quality of the deployed application and not simply the code. We are seeing that new technologies that are much more intermingled is a driving force for the Application Developer to be more aware of the operational environment. For example a COBOL developer will probably not care about the operational environment as much as a developer who uses Ruby, CSS, HTML5, JSP, Java, .NET, etc. It's this up-skilling on the front end that forces greater awareness of how things fit together. Application Developers generally do not want to be ignorant (I'm an application developer so I can say this). We want to learn and be more productive. What I have seen that works well is to team up application developer with a person from the Operations team that is responsible for reviewing software designs and operational skill transfer.

Infrastructure Specialist

 The Infrastructure Specialist is traditionally responsible for provisioning and configuring the infrastructure used for test and production environments. Provisioning of environments involves the setup of machines and networks and generally a standard operating system configuration. The Infrastructure Specialist's key responsibility is to ensure that an environment remains functioning at an acceptable level of quality usually captured as service level agreements (SLAs) in some form or fashion. Speed is generally not as important as stability and quality.

 With the emergence of DevOps the Infrastructure Specialist role changes to be more useful to the business by providing services to request infrastructure on demand. Cloud is often introduced into the equation to provide self-service and dynamic, programmable infrastructure (Infrastructure as a Service). That is to say that Cloud (or another virtualized platform) provides APIs to quickly and easily provision new virtual machines. The Infrastructure Specialist is also responsible for implementing standards within the virtualized platform such as standard Operating Systems, networking, and storage that encapsulate organizational requirements. The Infrastructure Specialist further increases their value to the business by moving beyond just providing Operating Systems to creating standard platform images (e.g., Application Server, Database, etc.) and even in some cases standard virtual patterns (see IBM SmartCloud Provisioning) which is often referred to as Platform as a Service (PaaS). The standard images and patterns are not created in a vacuum. Just as an Application Developer collaborates on the definition of the application architecture, the Infrastructure Specialist collaborates on the creation of standard virtual patterns to be used by the development teams.

Infrastructure Developer

 And now we come to a new role called the Infrastructure Developer but before we can describe this new role we have to discuss Infrastructure as Code. The idea of Infrastructure as Code has been around for a few years within the DevOps community. Carlos Sanchez has a blog simply titled Infrastructure as Code that does a nice job of stating the key points of Infrastructure as Code. For me the main point is that automation configuration of environments is evolving from basic scripts to new development languages (e.g., Chef and Puppet) for developing infrastructure code that should be developed and managed using the same rigor and tools as application code. We've stated in previous blogs that a team needs to plan and track everything as well as version everything. Infrastructure as Code and agile development tools provides teams with the ability to do just that. New technologies such as Chef and Puppet provide us with programming languages to develop and apply infrastructure configurations using the same development best practices (modular, self-documenting, test-driven) as application code. Tools such as IBM SmartCloud Continuous Delivery embrace and promote Infrastructure as Code development best practices.

 Just as an Application Developer develops application code, an Infrastructure Developer develops Infrastructure Code. It's that simple. What we hear from many customers is "Where do I find these Infrastructure Developers?" The good news is that most companies already have folks that can fill this new role. What I have found is that the role will be filled most likely by existing Infrastructure Specialists or Application Developers. Look for Infrastructure Specialists that are willing to learn and especially any that have a development background. An Infrastructure Specialist generally will not be successful if thrown into the new role without some training. You should expect to train an Infrastructure Specialist to be an Infrastructure Developer by

Teaching basic agile development practices

Teaching of new automation technologies such as Chef or Puppet

Teaching the use of agile development tools (e.g., IDE and SCM)

 Pairing an Infrastructure Specialist with an Application Developer is a great way to produce an Infrastructure Developer. As I pointed out, it is also possible that the Application Developer becomes an Infrastructure Developer if they have the ability and desire to gain enough operational skills to develop the necessary automation configuration code. However, pairing the two roles together is a good approach to produce a person (or two) that has the skills to develop high quality infrastructure code. There is a whole discussion about changing team dynamics that we will save for another blog post.

 In closing, DevOps is a major driver of change and process improvement within an organization. While change is scary, you have to ask yourself "What Would You Do If You Weren't Afraid?" as Haw does within the book. Sometimes change is good and absolutely necessary.

  Everyone is painfully aware that as technologies improve and evolve it becomes harder to deliver new features with quality to demanding customers. With new social and mobile applications customers have become trained to having their requests fulfilled within... 1 0 12985 urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bb Enterprise DevOps 2014-12-04T04:27:33-05:00 urn:lsid:ibm.com:blogs:entry-8ee74714-6388-4451-8972-bad09d137385 Wisdom from Mark Imbriaco @ the Triangle Meetup for DevOps mdelder 120000CYNE active false Entradas de Comentários Curtir true 2012-07-19T17:12:00-04:00 2012-07-20T07:35:40-04:00
 If you haven't heard about the Triangle Meetup for DevOps, it's time to do some research and get involved. Several of us from the IBM DevOps Team were fortunate enough to attend the Meetup last night. Mark Imbriaco stepped up to share some wisdom from his experience in the DevOps space. Mark was originally a sysadmin at 37signals, then was in operations at Heroku before becoming VP of Technical Operations for LivingSocial.

Mark focused a lot on the ratio of Developers to Operators; originally at LivingSocial, it was in the range of 50:1 (100 developers, 2 operators). He believes a better ratio is closer to 8:1. Ultimately, the smaller an operations team is, the more defensive it has to be and often is consumed by fighting more fires than rolling out innovative new applications. Mark also expressed that his philosophy was it's better to be innovative and down from time to time than to be constantly up and stifle innovation. He described the goals of operations as availability and efficiency, where efficiency was about making it easier and faster to deploy new applications.

 The importance of monitoring came up several times as well. At LivingSocial, they divide the monitoring rules and notifications into two sets: developers are notified when an application failure is detected, and operators are notified when a systematic failure such as a database outage is detected. The applications also embedded a configuration file that knows how to configure the monitoring for certain kinds of things, so that monitoring becomes a part of the application DNA. In some cases, both developers and operators are notified -- but Mark indicated that more often than not it's the application layer which detects a problem and notifies the developer. It was interesting to me because I've recently heard that mantra in other conversations with customers: developers can roll out whatever new innovative technologies that they want to use, so long as they own the pager. The flexibility of technologies used is a markedly different approach from when Mark arrived to the operations team at LivingSocial. Originally, there were specific supported versions and software (such as 1 version of ruby, 2 versions of rails, and all database access was done in MySQL).

 Mark also talked a lot about putting data into the cloud; I've heard other customers express hesitation at this, but he made a good point -- physical hardware fails just like virtual machines. If you have to account for redundancy and backup for physical hardware, why wouldn't you do it in a cloud environment as well? He also felt that the I/O bottleneck is often the biggest factor in application response times, and that it was solvable with money -- just ensure ever machine has 2 x 10Gbit NICs and 8+ SSDs. Then all storage gets dramatically improved responsiveness, which benefits the whole application.

 Mark gave us a good overview of LivingSocial's approach to Platform as a Service (PaaS), which was influenced by his experience at Heroku. Like all good projects, Mark said the first thing they did was come up with a good name -- AirSpace. All other naming is derived from that metaphor. When changes are delivered to Git, they have a post-commit listener which triggers behavior in a component called packer which produces "cargo". The "cargo" is then placed in a "cargohold" and awaits distribution by the ATC (Air Traffic Controller). Another component, carousel, knows which bits of cargo are associated with which applications. What I found very interesting was that they keep a set of base machines up ("autopilots") which watch for applications which need to be deployed. Their "airspace" command can take cargo from the cargohold and put it in a queue. Then the autopilots (pre-provisioned virtual images that conform to their base image), pick up work off of the queue. The first instance to get the cargo from the queue will configure itself with the application. When the running application is no longer needed (retired, fails, etc), the autopilot removes itself and frees up resources for new clean autopilots to run.

 This approach allows them to quickly deliver changes to a running environment and promotes a philosophy that every component of the PaaS is simple and serves a specific purpose -- much like the UNIX command philosophy. The usage of queues is prevalent to allow for easy scalability when needed.

 They also use hardware-based routing to shuffle traffic to autopilots which host applications, so they can easily route a percentage of the traffic to new autopilots when updates are rolled out. And if problems occur, the previous instances are still running, so rollback is simply an adjustment to the routing pattern.

 Our own Chuck Brant proposed that the name of a yet to be component to control that kind of logic be named "Control Tower", and the name seemed to stick. Way to go Chuck! :)

The turn out was really good (35-40) and had some recognizable names in the DevOps space like the author of Release It!. The Meetup group is now organized by Mark Mzyk of Opscode and he is aiming for a cadence of the third Wednesday of each month. So come on out and get engaged!

All in all, it was a great session and really demonstrates the interest in this area (both topically and geographically). Many thanks to Mark Mzyk for organizing the event and Mark Imbriaco for making time to come and talk to the group. Also, many thanks to WebAssign for hosting (now I'm a bit jealous of their offices ..).

* Image originated from the Office Clip Art Gallery

 If you haven't heard about the Triangle Meetup for DevOps , it's time to do some research and get involved. Several of us from the IBM DevOps Team were fortunate enough to attend the Meetup last night. Mark Imbriaco stepped up to share some wisdom from his... 1 0 4181 urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bb Enterprise DevOps 2014-12-04T04:27:33-05:00 urn:lsid:ibm.com:blogs:entry-4e9c85b4-4f64-4ed4-be78-c122b0530daa 12 Steps to Better DevOps mdelder 120000CYNE active false Entradas de Comentários Curtir true 2012-06-15T16:52:46-04:00 2012-06-15T17:00:32-04:00

 For those that follow Joel on Software, you may be familiar with his blog entry "The Joel Test: 12 Steps to Better Code". While authored way back in 2000, its content and statements are still relevant today. As people tried to understand Agile, the 12-step test provided a simple litmus test of concrete actions to help improve your over all software delivery.

Roll forward nearly a decade where DevOps is seeking to drive similar improvements to how operational aspects of software are delivered, managed, and maintained over time. Many people have explained their view of DevOps and what it takes to "live DevOps". I'd like to propose a similar set of concrete actions like Joel did for software to help explain my view of this topic.

Ultimately, DevOps is about trust. Trust between the Business & Development. Trust between Development and Operations. Trust among these groups enables the organization as a whole to be more agile and to better manage risk.

So how do we build trust? Consider the following 12 steps:

Do your developers and operators communicate the production realities and the application's requirements?

Do you version deployment configuration and scripts along with your source code?

Do you have patterns for platforms and applications, designed jointly by development and operations?

Can your developers launch and destroy production-like environments from those patterns?

Are your patterns based on reusable deployment configuration scripts?

Can you deploy an environment (platform and application) in one step?

Do you deploy your applications daily into production-like environments and verify them?

Do you link bugs and work items to changes in the application and configuration?

Do you associate tickets for production issues with relevant bugs opened for development to fix?

Do you have automated tests to validate your application and platform function and characteristics?

Do you monitor software against expectations after deploying your application?

Do you have a delivery pipeline exposed through a summary dashboard to assess delivery velocity?

 These steps are inspired by Joel's approach to explaining a new discipline, but follow the mantras that we've already recommended. Let's talk a bit more about these steps and I'll flag the association with the mantras in each case. You can reach more about the mantras in our first blog entry on the Invisible Thread.

1. Do your developers and operators communicate the production realities and the application's requirements?

[Track and Plan everything]

 Almost every customer we've ever talked to cites the lack of effective communication as a barrier to accelerated delivery. Often development and operations teams work in silos because that's how the executive hierarchy is configured. Each group is measured against a different set of metrics: change vs. stability. However, to ensure smooth delivery, it is absolutely imperative to establish how the needs of the application will be supported by the final production environment early in the process. The communication might be as lightweight as a face to face meeting where all concerns are discussed, a template to understand what capabilities are needed and provided, or something more detailed like a topology diagram. Regardless of the format, the information must be communicated early.

2. Do you version deployment configuration and scripts along with your source code?

[Version everything]

 Often, specialists are already creating deployment scripts today; bash, perl, python, wsadmin, ruby, chef, puppet are all examples of assets which help stand up environments. But for whatever reason, these assets aren't generally handled like the same .java, .jsp, .html or .ddl assets which make up the business logic of the application. Step 2 says that deployment configuration and script assets should be treated like valuable content just like the application source code.

 The idea is that the automation scripts and configuration files which have been left by the wayside as middleware evolved are brought back into the fold and considered part of the overall solution. Incorporating these artifacts into the same version control systems that have proven valuable for application source code means that you can more easily view and compare changes from prior deployments. If you're deploying the system completely through automation, it may also mean that rolling back a new deployment means simply re-applying the last approved version of the automation.

3. Do you have patterns for platforms and applications, designed jointly by development and operations?

4. Can your developers launch and destroy production-like environments from those patterns?

[Track and Plan everything]

Steps 3 and 4 are focused on enabling production-like systems to be leveraged earlier in the development process. Standard application and platform patterns are decided with collaboration between development and operations. Those patterns are then used by developers in an on demand form when they need to iterate quickly on changes for the application in their own isolated environment. When changes are ready for delivery, the build and deploy process should use the same patterns to deploy and verify each new build. The net is that both development and the continuous delivery process are using production-like patterns to verify their approach far earlier in the delivery process than what you may be used to today.

5. Are your patterns based on reusable deployment configuration scripts?

6. Can you deploy an environment (platform and application) in one step?

7. Do you deploy your applications daily into production-like environments and verify them?

[Automate everything]

 Steps 5, 6, and 7 each deal with automation -- but unlike traditional automation approaches, DevOps generally uses automation technologies which have file-based persistence, which are declarative rather than imperative, and which are applied, applied, and applied over and over again. Many organizations have already bought into the value of automation, but often focus on automation above the platform layer -- to deploy the application into an existing platform. DevOps takes the end goal a step further to stress automation to create the entire solution -- from the platforms all the way to the end user.

DevOps asks the same kind of questions about deployments that agile software asked about builds. The ability to do a build in one step enabled us to perform builds more frequently ensuring that everything compiles. Similarly, being able to do a deployment in one step enables more frequent deployments. If a problem is introduced, you want to find it early and fail fast.

 There's a subtly here that may be overlooked and I want to call your attention to it. If you're providing production like environments to validate the application, you're also able to validate the platforms that are supporting the applications. Hence any new platform updates that you plan to roll out feed into the pipeline just like application builds. If your middleware platform needs to be updated, you would roll that change out first early in a development stage of your pipeline. Just as application artifacts are graduated through the pipeline as they pass their verifications, so are changes to the infrastructure components like your middleware. Treating application and infrastructure components like equal citizens means that there isn't a special exception process for one kind of change or another -- all changes go through the same journey together in harmony.

 Ultimately, steps 5-7 hint at a role transition that occurs in DevOps where operations engineers no longer act as administrators but more as content creators -- as infrastructure developers. Like software developers, infrastructure developers create automation to provision and maintain the infrastructure, platforms, and applications in each stage of your pipeline.

8. Do you link bugs and work items to changes in the application and configuration?

9. Do you associate tickets for production issues with relevant bugs opened for development to fix?

[Track and Plan everything]

Steps 8 and 9 talk about how changes are tracked. Joel asked you if you had a bug database. We're asking if you link bugs or work items directly to the affected changes in your version control. It's important to have this level of traceability so you can identify why a particular change was introduced and ideally what related files were touched. If you want to see what this looks like, take a look at jazz.net. And since you're tracking changes to your deployment configuration and scripts (as in Step 2), that means that changes to those artifacts also go through the bug database and are then deployed and tested just like application code.

No matter how much some of us developers would like to think the real work is done once an application reaches production, it's not! When problems happen in production, there's generally an existing process for tracking incidents. We're suggesting that whenever incidents are encountered, an incident ticket should be opened and linked directly to defects in either the software or configuration layer, ensuring traceability from end to end. The bug or work item enables you to track when a fix is released to the application or configuration and know when the ticket can be closed. Knowing what the incident looked like in production means you can also beef up test cases so that a regression isn't introduced in the future. It doesn't matter if the root cause is in the business logic or an invalid datasource configuration, the changes should be treated and managed in the same way. Since bugs are linked to changes (Step 8), you'll know what had to change to fix the incident.

10. Do you have automated tests to validate your application and platform function and characteristics?

[Test everything]

 The goal here is to ensure that your provisioning process is meeting the expectations of stakeholders including development, quality assurance, and operations. Other stakeholders like performance and security testing may also play a role. Software development did this first with compilation. It ensured that all of your source code could be translated into a machine readable format. Errors were quickly reported as part of the build process. Then agile promoted the notion of incorporating unit tests, static analysis, and other security compliance scans. DevOps expands that notion to also testing the deployed software and its supporting platforms. Steps 7 and 10 ensures that you actually use it regularly!

11. Do you monitor software against expectations after deploying your application?

[Audit and Monitor everything]

 Most production systems already have some level of monitoring in use today. Exposing production-like patterns and environments earlier should mean that monitoring capabilities are available to developers. Hence, developers and operators have the opportunity to verify that application code is being written to be easy to monitor. Just like knowing what an incident looks like can help you beef up test cases, knowing what kind of information is (or isn't) coming from an application's monitoring capabilities will help you understand how to provide better feedback in production. Like Steps 7 and 10 are about providing continuous feedback about the function of the application, Step 11 is about validating expectations for performance and reliability through monitoring early in the process.

12. Do you have a delivery pipeline exposed through a summary dashboard to assess delivery velocity?

[Dashboard everything]

 Almost all organizations have a loosely defined, loosely coupled notion of delivery pipeline. Establishing a common understanding of what stages an application must pass through on the way to production ensures that hand offs are predictable and tracked to ensure accountability. Beyond that, providing progress reports about applications and their location through the pipeline -- from inception to happy end user -- is critical to ensure that you're constantly improving the overall delivery response time.

 A lot of this process also means establishing the right metrics for your organization at a higher level and ensuring that those metrics can be tracked. An example metric might include something like "how long does it take to release a no-change version of my application?" That is, if you don't change a single line of source code, how quickly could you get the current version rolled out into production (starting in development)? Often (surprisingly) this time is non-zero. A lot of it may include manual configuration and intervention which limits how quickly it can be done. Again, focusing on automation from barebones to happy user means that you can increase your delivery velocity with managed risk.

In closing, while this article is by no means fully prescriptive of how to transform your organization, I hope it has at least inspired some thoughts about how you might begin incremental adoption of the techniques encouraged by DevOps.

I would like to thank Bill Mitlehner and Jeff Imholz for their contribution to the ideas expressed in this article.

 For those that follow Joel on Software , you may be familiar with his blog entry " The Joel Test: 12 Steps to Better Code ". While authored way back in 2000, its content and statements are still relevant today. As people tried to understand Agile,... 2 0 15808 urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bb Enterprise DevOps 2014-12-04T04:27:33-05:00 urn:lsid:ibm.com:blogs:entry-c197fa77-d7ca-46a2-8dcc-bd31b4ea2a1a DevOps at IBM Innovate 2012 next week DanBerg 0600006G7X active false Entradas de Comentários Curtir true 2012-06-01T21:53:36-04:00 2012-06-01T21:53:36-04:00

As conference season continues we are now coming upon IBM's Innovate 2012 conference held in sunny Orlando FL at the Walt Disney World Swan and Dolphin Resort. If you will be attending the conference this year please check out some of our DevOps specific sessions where you can meet several of the authors of this blog such as myself, Michael Elder, and Steve Abrams. We have a list of the DevOps specific sessions at Lanyard.com.

At the Innovate conference there will be many demonstrations showing integrated tools and capabilities in support of DevOps and more generally Application Lifecycle Management. We will be showing some of the demos during the main tent keynotes on Monday and you may get up close and personal with the demons downstairs in our Integration Center. In the Integration Center we will have several pedestals which will be linked together on a shared network with linked demonstrations using IBM and open source tooling.

For all of you old folks like myself you will enjoy the entertainment on Wednesday where Foreigner will be performing. For the youngins we have a fun evening with the fish at Sea World.

See you there!

 As conference season continues we are now coming upon IBM's Innovate 2012 conference held in sunny Orlando FL at the Walt Disney World Swan and Dolphin Resort. If you will be attending the conference this year please check out some of our DevOps specific... 1 0 3955 urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bb Enterprise DevOps 2014-12-04T04:27:33-05:00 urn:lsid:ibm.com:blogs:entry-74cb7153-7875-458d-b558-9f9902e3886e Are you treating your servers like snowflakes or rubber stamps? ann_marie_99 06000073UA active false Entradas de Comentários Curtir true 2012-05-23T11:02:25-04:00 2012-06-12T08:43:33-04:00
 I was inspired by this entertaining article by Alex Tatiyants: DevOps is Ruining My Craft.

A favorite analogy in the DevOps community is that the "old style" of IT server management, where people can make manual changes to their servers, leads to production servers that are unique and precious, like snowflakes. If you don't completely automate the configuration of your servers, your chances of re-creating the exact same server twice are nearly zero, just as no two snowflakes are alike. And because you can never re-create a production server, you must do everything in your power to protect it from changes that can break it.

The problem with this approach is that it creates an adversarial relationship between developers, who want to change the servers often to release new features, and operations professionals, who want to keep the servers running and safe. Operations teams tend to "lock down" the production servers and only allow changes to them on rare occasions. This makes business-critical software less agile and more difficult to change.

 So what's the alternative to servers as snowflakes? Servers as rubber stamps! We advocate automating everything, so that your servers can be re-created on demand. Do you want another web server? Ca-chunk, here you go. Do you want another web application server? Ca-chunk, no problem.

Creating a new server for each release of new code, and replacing the old server with the new one, simplifies "rolling deployments" into production and other techniques that DevOps advocates recommend.

Do you want to add a new web application to your site? Stamp out a new web application server with the new application on it, test the new website in a staging environment, re-configure the tested server so it's available in your production server pool, and then redirect your web traffic to go to the new server instead of the old one.

Cloud computing is the enabling technology that makes "rubber stamp" servers easy. While you can automate the configuration of standalone servers, it's dramatically simpler to automatically create and configure new servers in a cloud for every code change. When you start with a clean virtual machine image every time, the new systems that you create will be almost identical to one another when they start up. When you then automate every step of the configuration process with infrastructure automation code, you can be sure that your systems will be configured in a repeatable way.

These techniques have already been put into practice by other DevOps leaders, including Etsy, Facebook, and Flickr. At IBM we're developing new tools and integrations between existing tools, to make DevOps principles and practices easier for our enterprise customers to adopt. One such solution is IBM SmartCloud Continuous Delivery, which we're developing now.

I work on the IBM SmartCloud Continuous Delivery development team, and we are using SmartCloud Continuous Delivery to build SmartCloud Continuous Delivery. For example, we use Rational Team Concert with our Continuous Delivery plug-ins as our development environment, and we use our Continuous Delivery build definitions to automatically create new test servers in the cloud every time we deliver a code change.

IBM's Virtual System Patterns make infrastructure automation even easier. Rather than starting with virtual machine images, we start with pre-configured patterns that already include the prerequisite software for our application. These patterns are available with IBM Workload Deployer today, and they also will be available with the new IBM PureApplication Systems and the next version of SmartCloud Provisioning.

You can think about a Virtual System Pattern like a rubber stamp for virtual systems. For example, if your production system includes multiple WebSphere Application Servers and DB2 servers, you can use this Virtual System Pattern as a starting point:

There's a lot of detail in this screenshot, but here are some of the more interesting things that this Virtual System Pattern handles for us:

When you deploy this pattern, it will automatically deploy, start, and configure all of the systems for you.

There are different types of servers here, including the Deployment Manager and Custom Nodes (for WebSphere Application Server), HTTP servers, and DB2 servers running in Primary and Standby modes.

By default this Virtual System Pattern will create one of each server and two Custom Node servers, but those numbers are configurable. If you want 5 Custom Nodes and 3 HTTP servers, you can change those values at deployment.

The Virtual Machine images have been optimized, and additional tuning can be done at deployment, such as the "JVM tuning" on the Custom Nodes.

The servers have been configured to work together, such as the "Cluster configuration" on the Deployment Manager.

The servers have been secured and patched using the "iwd_VMCompliance" script package that our operations team automatically adds to every pattern.

The "DevOps Bootstrap" script package is the hook that enables our Continuous Delivery process. When that script runs, it will run our infrastructure automation code to finish configuring the servers, install our new application, and start it.

Starting with a Virtual System Pattern is useful because it saves developers from having to worry about everything listed above. Also, those systems have already been optimized for the best performance, reliability, availability, and security by someone with real-world operations experience. Finally, using a pre-defined pattern reduces the number of different configurations that the development and operations teams need to support. We don't even need to write installers for applications that only need to run in our cloud environment; we just write automation code that assumes we're creating a brand new server, and we can make assumptions about what's already installed and configured on the server. That saves us time that we can use to do more important things.

Creating and configuring new servers in the cloud is also orders of magnitude faster than the same activities outside a cloud environment. Most of my team's test systems (which usually include 1-2 VMs) are up and running within 15-30 minutes after a developer delivers new code. That includes building the application and infrastructure automation code, publishing it to the software library, provisioning and starting multiple VMs, installing and configuring the prerequisite software (like the application server and database) on all of the VMs, installing and configuring our application on the correct VMs, starting all of the services, and even testing the running servers! We can do several of these deployments in parallel as well, and it's not unusual for my development team to run through this entire automated process several times every day. And when we're done with test systems, we can automatically delete them.

There will always be a need for some long-running production servers, and some applications don't lend themselves to this type of deployment as well as others. However, creating new virtual systems for every code change is ideal for development and test teams, and that's why we started with development and test tooling for SmartCloud Continuous Delivery. We're currently working toward our first betas for SmartCloud Continuous Delivery. Over time we hope to extend our DevOps tooling support to enable more extensive operational testing, deployments into production, and incident management.

We've seen how SmartCloud Continuous Delivery, along with Virtual System Patterns, can help create and test new virtual systems automatically. SmartCloud Continuous Delivery is designed to get rid of the bottleneck caused by waiting for someone to set up new test servers. It allows us to test a running multi-server system after every code delivery, and when we do that, it's much easier to catch bugs and fix them earlier. Finally, when operations teams are confident that new code has been tested well, they can allow developers to release changes into production more often. This allows businesses to be more agile and react to change more quickly.

Goodbye, snowflakes. Hello, rubber stamps!

 I was inspired by this entertaining article by Alex Tatiyants: DevOps is Ruining My Craft . A favorite analogy in the DevOps community is that the "old style" of IT server management, where people can make manual changes to their servers, leads to production... 2 0 11646 urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bb Enterprise DevOps 2014-12-04T04:27:33-05:00 urn:lsid:ibm.com:blogs:entry-98556d97-a1c9-4313-9798-d8a0f4b55966 DevOps at Impact 2012 DanBerg 0600006G7X active false Entradas de Comentários Curtir true 2012-05-14T16:10:15-04:00 2012-05-14T21:17:58-04:00 <title>DevOps</title>
I and many of my fellow cloud and DevOps colleagues attended and presented DevOps specific sessions at the recent IBM Impact 2012 conference in sunny Las Vegas. The conference had over 8,500 participants flooding the Venetian. The key technology trends discussed at the conference were:

Cloud

Mobile

BPM

DevOps (our favorite)

One of the biggest announcements at the conference was the announcement of the new IBM PureSystems which include IBM PureFlex and PureApplication. These are IBM's new workload optimized cloud environments providing dramatic effeciencies for customers who are looking to adopt a private cloud platform.

As we saw last year, Mobile continued to be a hot topic as many more customers seemed to be exploring ways to build native and hybrid cloud applications. IBM's Worklight tools and runtime sessions were in high demand as customers feel the pain of having to support multiple mobile platforms. Worklight provides capabilities to build a single application that can be natively hosted in multiple mobile platforms.

What we learned while at the Impact conference is that as more customers move to adopt Cloud (and Agile development practices) there is a greater desire for enterprises to learn more about DevOps and how aspects such as Continuous Delivery can improve their ability to delivery faster business results with higher quality. We also heard many customers that are interested in adopting Mobile have found that Mobile development requires faster delivery times. Plus Mobile deployments are generally more complex than a traditional web application. For these reasons alone customers have begun to understand that they must adopt DevOps practices and continuous delivery to have any hope of being able to rapidly deliver changes for mobile applications. For example I conducted a lightning talk at the Developers Mini Main Tent: "The New Development Reality" where I spoke about the DevOps practice of capturing Infrastructure as Code and managing and building the code using Agile practices and tools. You can read more about the Developers Mini Main Tent at the IBM Impact blog.

As more customers begin to realize that they have to adopt DevOps methodologies and tools we see them quickly hone in on the fact that the cultural changes will be necessary and will be difficult. Thus we are being asked "How should our organization change to adopt DevOps?" As everyone knows the greatest challenge when adopting DevOps is dealing with the cultural changes that must be made. Another challenge is how to communicate the value of DevOps to executives which is very important because you need executive buy-in to be able to make the cultural changes. We'll be exploring different cultural change scenarios and best practices in future blog posts.

IBM Innovate 2012 is right around the corner. I hope to see you there because we will be performing some very interesting integrated continuous delivery demonstrations.

 DevOps I and many of my fellow cloud and DevOps colleagues attended and presented DevOps specific sessions at the recent IBM Impact 2012 conference in sunny Las Vegas. The conference had over 8,500 participants flooding the Venetian. The key technology trends... 1 0 4487 urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bb Enterprise DevOps 2014-12-04T04:27:33-05:00 urn:lsid:ibm.com:blogs:entry-9d91c4f5-ce5b-4f86-b0ca-e2e6773cf0db Devopsdays - Austin 2012 jryding 270000Y99R active false Entradas de Comentários Curtir true 2012-05-04T11:19:53-04:00 2012-05-15T07:38:24-04:00
In early April, a couple members of the IBM DevOps team went to Austin, Texas to attend the Devopsdays Austin 2012 conference. This was a conference that is put on by members of the DevOps community to help get people from different organizations together to share ideas and learn from each other. We met a bunch of smart people and learned a lot about how some teams have implemented DevOps practices in their orgnanizations. Today, I want to talk about a couple topics that the IBM DevOps team has been researching and were important themes at the conference.

The Importance of Culture

The adoption of DevOps practices requires looking at two components in delivering software: technology and culture. The technical component addresses the practice of focusing on automating an application's deployment, incorporating version control, and using various tools to gain insight into how software is being built and deployed. The cultural aspect of adopting DevOps requires an organization to look at its processes of delivering software and figuring out how teams can move faster. As Steve alluded to in his last post, one of the challenges of adopting DevOps is that development cultures and operations cultures are different. To grossly oversimplify a complex topic, developers are generally focused on shipping new features quickly and operations is generally focused on system stability, performance, security, and other operational quality characteristics. To embrace DevOps, these two groups need to collaborate on a single goal: delivering on the needs of the business. The separate groups need to learn how to work with one another; they need to trust and respect the domain of expertise each group has. When problems do occur (which is inevitable when changing a complex system), blaming each other won't fix anything. Instead, the teams need to focus on the real issue: the problem itself. John Willis put this best:

"When we go into the war room, the problem is the enemy."

When issues in production do occur, working together as a single team that is solving a problem is the goal and learning how to address and/or prevent the problem in the future should be the outcome. The DevOps community is doing some amazing work around tooling that take advantage of cloud technologies but, much like the Agile movement, using these tools won't instantly save organizations from inefficient processes. Addressing these bottlenecks in application delivery and finding a balance between moving fast while maintaining proper governance is a significant part of getting an organization to adopt DevOps.

Security in DevOps

In the way that DevOps is evolving operations groups, the same is going to happen to security teams that do not collaborate well with development groups. Security teams are a lot like operations groups, both provide a domain of expertise and are required to protect the business from problems. Unfortunately, as James Turnbull of Puppet Labs puts it, security has emerged as the organization that tends to always say "no" due to fear of exposing the business to an external threat. This inevitably creates friction between security and the rest of the business: development thinks that the security group gets them in trouble and the business leaders think they have to move slow before introducing a radical change. These views of the security group needs to change, or else the development and business leaders will figure out a way to circumvent them.

In the world of DevOps, security needs to change the same way operations is changing. Security people need to collaborate closer with development so that both groups understand the needs of one another. No one wants to allow the external threats affect the business, but few people have the knowledge to properly protect themselves. Giving security a seat at the project design table or embedding someone inside the development team will help greatly with breaking down these walls. James Turnbull and Nick Galbreath (Etsy) really hit the nail on the head by acknowledging that instead of security groups looking at themselves as the last gatekeepers to protecting the business, they need to evolve into consultants and knowledge experts that help deliver on the neesd of the business. With this view in place, these groups can help teach the business leaders and development teams what exactly needs to be done to help.

Conclusion

DevOps Days Austin was a great event full of smart people. We learned a lot from our time there. The aspect of changing an organizations culture to accommodate the efficient processes of DevOps is a significant topic. It's going to affect many groups and if the culture of collaborating across teams is not in place, no DevOps tool will help. We will be exploring the topic of culture more in future articles and invite other DevOps community members to provide their input.

If you are interested in attending one of the many Devopsdays events occuring around the world this year, be sure to check out the [DevOps Days website](www.devopsdays.org). You can also view the recorded presentations from Devopsdays Austin 2012 online.
 In early April, a couple members of the IBM DevOps team went to Austin, Texas to attend the Devopsdays Austin 2012 conference. This was a conference that is put on by members of the DevOps community to help get people from different organizations together to... 1 0 4795 urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bb Enterprise DevOps 2014-12-04T04:27:33-05:00 urn:lsid:ibm.com:blogs:entry-066ddcb7-ef6d-4f61-83a7-95ba6d7a6a88 Welcome to the Enterprise DevOps Blog SteveAbrams 270000YJ02 active false Entradas de Comentários Curtir true 2012-04-26T16:23:17-04:00 2012-04-26T17:29:17-04:00

Delivering quality software on-time and on-target is hard. With so many stakeholders involved, it's no wonder. Each has different perspectives, cultures, languages, priorities, and work cadences. Since changes can cause breakage, bureaucracy flourishes which limits the ability of the business to compete and meet the needs of their customers.

Of course this is something of a caricature, but it does highlight one of the key problems in software delivery: the existing organizational silos, processes, and technologies often do more to keep the stakeholders apart than to foster collaboration.  To put it mildly, there are tremendous opportunities for improvement in the world of enterprise software delivery. Cycle times run way too long; defects due to misconfigured infrastructure and middleware waste time, money and effort; developers have a hard time diagnosing and fixing production errors because they can't get access to similarly configured systems; production teams can't depend on build quality, etc.

Practices such as iterative and agile software development primarily focused on the gap between the first two stakeholder groups – the business and the development teams. Frequent iterations, feedback from business stakeholders early and often, and a focus on quality all help teams communicate and collaborate towards a common outcome: working software that provides business value. All too often, the collaboration does not include the operations teams. Enter DevOps. DevOps is an emerging set of principles and practices aimed at the second gap – between development and operations.  Conceptually, DevOps extends the practices of agile to include the deployment and management phases of the lifecycle.

As we've already discussed, a disciplined approach to DevOps is critical for enterprises to successfully bridge this gap -- at least as critical as a disciplined approach to agile development is. Practices such as continuous build, test, integration, and delivery can help organizations move more quickly – but those need to be coupled with appropriate governance, versioning, and quality checks. Malleable cloud infrastructure lets us easily stand up new infrastructure – but that infrastructure needs to be designed in collaboration between development and operations to ensure that it meets everyone's objectives. In general, we need to combine technologies and practices that encourage speed with mechanisms that increase visibility and reduce risk. That is Enterprise DevOps.

With announcements such as our forthcoming Smart Cloud Continuous Delivery beta, IBM is starting to pay much more attention to the emerging DevOps movement. In this blog, members of the IBM DevOps community will share our latest thinking on DevOps and how it can be applied at enterprise scale. The focus will not be on products. We will try to talk equally about the changes in people, process, and technology that are necessary to help businesses accelerate their software delivery lifecycle. We look forward to comments and feedback from anyone interested in this topic – customers, business partners, analysts, and even competitors. We hope this blog becomes an interesting forum for conversation about the emerging topic of Enterprise DevOps.

  Delivering quality software on-time and on-target is hard. With so many stakeholders involved, it's no wonder. Each has different perspectives, cultures, languages, priorities, and work cadences. Since changes can cause breakage, bureaucracy flourishes which... 1 0 5160 urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bb Enterprise DevOps 2014-12-04T04:27:33-05:00


text:
You need to log in to use this feature. By registering with magicseaweed.com you can keep a watch list of your favourite spots, upload, tag and keep a gallery of your favourite photos, report on and diary your latest sessions and more. It's completely free now and forever.
Log In
No Account? Sign Up Now

subset: commoncrawl


text:
Dr. Barbara Pinson MD
- Occupational Medicine Longview, TX
Patient Reviews
Reviews reflect patients' level of satisfaction with the care they received from this provider. Dr. Barbara Pinson does not yet have any reviews.
Dr. Barbara Pinson, MD is a Doctor primarily located in Longview, TX, with other offices in Tyler, TX and Tyler, TX. She has 24 years of experience. Her specialties include Occupational Medicine. Dr. Pinson is affiliated with Good Shepherd Medical Center-Linden, Good Shepherd Medical Center and Ut Health Center At Tyler. She speaks English.
Find out the languages this doctor/ or staff may speak.
View all
Learn where this doctor attended medical school.
View all
Specialties & Expertise
Dr. Barbara Pinson has the following 1 specialty.
Occupational Medicine
You might work with an occupational therapist when you're injured or if you have a disability. They rehabilitate and assist patients with every day activities, such as eating, getting dressed, working and attending social events. This includes self-care, leisure and work-related activities that lead to increased independence and development. Their goal is to empower people to still live the life they want despite any physical, developmental, social and/or emotional issues they might face.
Health Guides
Get the facts about chronic obstructive pulmonary disease (COPD), including symptoms and complications.
more health guides
Locations & Directions
Nearby Doctors
Dr. Barbara Pinson, MD is similar to this 1 Doctor near Longview, TX.


text:
Stereotactic Radiosurgery in Treating Patients With Stage I or Stage II Non-Small Cell Lung Cancer
- Full Text View
- Tabular View
- No Study Results Posted
- Disclaimer
- How to Read a Study Record
RATIONALE: Stereotactic radiosurgery can send x-rays directly to the tumor and cause less damage to normal tissue.
PURPOSE: This phase I trial is studying the side effects and best dose of stereotactic radiosurgery in treating patients with stage I or stage II non-small cell lung cancer.
|Lung Cancer
|Procedure: computed tomography Radiation: fludeoxyglucose F 18 Radiation: hypofractionated radiation therapy Radiation: stereotactic radiosurgery
|Phase 1
|Study Type:
|Study Design:
|Intervention Model: Single Group Assignment
Masking: None (Open Label)
Primary Purpose: Treatment
|Official Title:
|Feasibility and Outcome of Cyberknife® Precision Hypofractionated Radiosurgery for the Curative Management of Non-Small Cell Lung Cancer
- To establish the maximally tolerated dose of CyberKnife® radiosurgery in patients with medically inoperable clinical Tl-3 N0 M0 NSCLC [ Time Frame: 6 weeks ]
- Relationship between PET response and local control and survival as measured by fludeoxyglucose F 18 PET/CT imaging [ Time Frame: before treatment and at 1, 3, 6, and 12 months after treatment ]
|Estimated Enrollment:
|Study Start Date:
|January 2009
|Estimated Study Completion Date:
|March 2018
|Primary Completion Date:
|June 2013 (Final data collection date for primary outcome measure)
|Assigned Interventions
Experimental: CyberKnife
Procedure/Surgery: computed tomography Standard CT scans
Radiation: fludeoxyglucose F 18 standard doses with CT scans
Radiation: hypofractionated radiation therapy 4 doses over 2 weeks
Radiation: stereotactic radiosurgery CyberKnife radiosurgery
Procedure: computed tomography
Standard CT scansRadiation: fludeoxyglucose F 18
standard doses with CT scansRadiation: hypofractionated radiation therapy
4 doses over 2 weeksRadiation: stereotactic radiosurgery
CyberKnife radiosurgery
Detailed Description:
- To establish the maximum tolerated dose of CyberKnife® hypofractionated stereotactic radiosurgery in patients with medically inoperable, stage I or II non-small cell lung cancer.
- To establish the relationship between PET response and local control and survival using fludeoxyglucose F 18 PET/CT imaging before treatment and at 1, 3, 6, and 12 months after treatment.
OUTLINE: Patients undergo placement of 3 gold fiducial markers by CT-guidance or bronchoscopy. Patients then undergo CyberKnife® hypofractionated stereotactic radiosurgery over 45-120 minutes twice weekly for 2 weeks.
Patients undergo fludeoxyglucose F 18 PET/CT scan at baseline and at 1, 3, 6, and 12 months after completion of treatment.
After completion of study treatment, patients are followed periodically for up to 4 years.
|Ages Eligible for Study:
|18 Years and older (Adult, Senior)
|Sexes Eligible for Study:
|Accepts Healthy Volunteers:
Inclusion Criteria:
Histologically confirmed non-small cell lung cancer
Stage I or II disease (T1-3, N0, M0)
- T2 or T3 tumor ≤ 5 cm
- No T3 tumors involving the central chest or mediastinum (only chest wall involvement allowed)
Tumor deemed technically resectable, in the opinion of an experienced thoracic surgeon, AND patient deemed "medically inoperable"
- Patients with FDG-avidity in mediastinal lymph nodes are eligible provided they are able to undergo mediastinoscopy to confirm N0 status
- ECOG performance status 0-2
- Not pregnant or nursing
- Fertile patients must use effective contraception during and for ≥ 6 months after completion of study treatment
Exclusion Criteria:
- No history of contrast allergy
- No psychological issues that would preclude the completion of study treatment
- No prior radiotherapy or chemotherapy
- No suspected nodal metastasis that cannot be falsified by mediastinoscopy (i.e., hilar or mediastinal nodes that are either fludeoxyglucose F 18 [FDG]-avid or measure > 1 cm in short axis diameter on CT scan)
- No tumor within or touching the proximal bronchial tree, defined as a volume of 2 cm in all directions around the proximal bronchial tree (carina, right and left main stem bronchi, right and left upper lobe bronchi, bronchus intermedius, right middle lobe bronchus, lingular bronchus, right and left lower lobe bronchi)
Please refer to this study by its ClinicalTrials.gov identifier: NCT00852644
|United States, Massachusetts
|Boston University Cancer Research Center
|Boston, Massachusetts, United States, 02118
|Principal Investigator:
|Lisa A. Kachnic, MD
|Boston Medical Center
|Responsible Party:
|Salli Fennessey, Study Coordinator, BUCRC, Boston Medical Center
|ClinicalTrials.gov Identifier:
|NCT00852644 History of Changes
|Other Study ID Numbers:
BUMC-H-26701 ( Other Identifier: BUMC IRB )
|Study First Received:
|February 26, 2009
|Last Updated:
|March 16, 2016
Keywords provided by Salli Fennessey, Boston Medical Center:
stage I non-small cell lung cancer
stage II non-small cell lung cancer
Additional relevant MeSH terms:
Lung Neoplasms
Carcinoma, Non-Small-Cell Lung
Respiratory Tract Neoplasms
Thoracic Neoplasms
Neoplasms by Site
Lung Diseases
Respiratory Tract Diseases
Carcinoma, Bronchogenic
Bronchial Neoplasms
Fluorodeoxyglucose F18
Molecular Mechanisms of Pharmacological Action
ClinicalTrials.gov processed this record on September 21, 2017


text:
STARmeterTop 500
Up 45 this week
Steve Carell
Steve Carell, one of America's most versatile comics, was born Steven John Carell on August 16, 1962, in Concord, Massachusetts. He is the son of Harriet T. (Koch), a psychiatric nurse, and Edwin A. Carell, an electrical engineer. His mother is of Polish descent and his father is of Italian and German ancestry (Steve's grandfather had changed the ... See full bio »
Born:in Concord, Massachusetts, USA
More at IMDbPro » Contact Info: View agent, manager, publicist and company


text:
'Since the Sabres came into the NHL, they have played 1,333 home games to date counting both the old Memorial Auditorium and the HSBC Arena. Smart has only missed eight games, most of them due to being hospitalized. On top of that, the Sabres have played 104 Stanley Cup playoff games at home and Smart has never missed one.'
You are here: Home / SabresBeat / Fan in focus


text:
i think miz is annoying as a face. flair and ziggler make a better heel pairing then flair and miz make as a face pairing. cause flair is better as a heel. but both miz and ziggler don't need flair.
I'm the best in the world, and you can rest in piece.
Last edited by thedag; 01-17-2013 at 07:37 PM.
"If the devil can't defeat me, cancer doesn't stand a chance in hell! Pray for sick children who face this horrible disease 'cause The Snake will be just fine."
Get well soon Jake 'The Snake' Roberts
Jessie J has nothing on her
I'm the best in the world, and you can rest in piece.
I want to know who looked at David Otunga and said "You know something? This guy's good." They deserve to be fired.


text: GW girls stun Morgantown By Tommy R. Atkinson November 6, 2012 Story Share Three out of four ain't bad.The Kanawha Valley sent three teams to the boys and girls Class AAA championship games Tuesday in the state high school soccer tournament.Sophomore Sara Bodnar scored off a feed from senior Andrea Breeden in overtime as the Patriots upset defending champion and unbeaten Morgantown 2-1 in the girls semifinals at Schoenbaum Soccer Stadium in Coonskin Park. Senior Emily Cole set up Winfield's first goal and scored another as the Generals rolled past Buckhannon-Upshur 3-0 in an earlier semifinal.On the boys side, Hurricane received goals from four different players to sweep past Hedgesville 4-0 while Parkersburg held on against defending state champion GW 1-0.GW (18-4-1) will square off with Winfield (19-1-2) at 10 a.m. today, setting up an all-Kanawha Valley match in the girls finals at Schoenbaum. The Generals easily handled the Patriots 4-1 during the regular season. This will be the first time two teams from the Valley will clash in the finals since the girls tournament began in 1995.For the boys, undefeated Hurricane (22-0-1) will take on Parkersburg (17-3-2) in the title game at approximately 12:15 p.m. today at Schoenbaum in a battle of the top two teams in AAA in the final state coaches association rankings. The Redskins and Big Reds played to a 1-1 draw in the regular-season finale.The SSAC postponed the state tournament last week, then moved it to Charleston 16 inches of snow fell on Beckley, where the tourney was scheduled to be held. Teams hadn't played since regionals Oct. 23-25.The No. 6 Patriots girls advanced to the finals for the third time but are still seeking their first title after losses in 1999 and 2010. Winfield is looking for its first championship since winning the first three girls crowns from 1995-97.GW defeated Capital in the sectional finals a year after the Cougars upset the No. 1 Patriots, then downed Princeton in the regionals after falling to the Tigers in the Mountain State Athletic Conference championship game. The Patriots lost to Morgantown 3-0 with several starters out with injuries to close out the regular season."After losing to [Morgantown], we were hungry,'' said Bodnar, who netted the only goal in the victory over Princeton in regionals. "Everyone doubted us coming into the tournament. We proved them wrong.''The No. 3 Winfield girls has lost heartbreakers the last two years at states, falling 1-0 in a penalty-kick shootout to Morgantown in last year's championship game and losing 1-0 to eventual state titlist University two years ago in the semis on a last-second goal. The Generals finally broke through in overtime, though, beating Huntington 1-0 in the regionals."From Aug. 1, we've been working really hard,'' said Cole. "We've done everything to prepare ourselves for this. Everyone keeps saying the third time is the charm and you just have to believe it. We've gone farther and farther every year. I think this is it. This is our chance.''In the boys division, No. 1 Hurricane has advanced to states for the fourth time in the last six years, losing to GW 1-0 in the title game in 2007, falling to Wheeling Park 2-1 on penalty kicks in the semis in 2010 and lost 1-0 to eventual state titlist GW in last year's semis."They've had a remarkable three years, losing two regular-season games,'' said Hurricane coach Jim Dagostine of his seniors. "All year they've been interesting to coach and they've brought a lot of joy and excitement to our community and school.''No. 2 Parkersburg will be playing in its nine championship with six titles but none since the last of back-to-back titles in 2009. The Big Reds, though, haven't won a final outside of Beckley. A capsule look at Tuesday's semifinals:Girls GW 2, MORGANTOWN 1: Breeden fought for the ball near the right end line, then battled past another defender before crossing the ball to Bodnar in front of the net for what proved to be the winning goal with 3:56 left in the second 10-minute OT period, which is played in full. "I knew if I put it on Sarah's foot, she'd be there and have a good shot,'' Breeden said. "I trust her.''The No. 1 Mohigans didn't mount much of a counterattack the rest of the way. Morgantown (22-1-1) had several chances before Bodnar's tally, but was turned aside each time by GW sophomore keeper Olivia Miller, who finished with 11 saves and had several diving stops. "We came in being the underdogs and that's our element,'' said Miller, who sat out the first meeting with Morgantown with an injury. "I held my breath the whole time. We want it so bad. I'm so proud of my team. I wouldn't want to be anywhere else.'' As time expired, the GW bench emptied onto the field as the improbable celebration began. Morgantown, which had been ranked for much of the season in the National Soccer Coaches Association of America national fall rankings, had only allowed three goals all season. Mohigans junior forward Maggie Snively, the team's leading scorer, injured her arm in the first half and did not return.The Patriots surprised from the beginning as Breeden scored off a setup from senior Charlie Lucente for a 1-0 lead about halfway through the opening half and stayed that way until late in the second half.Junior Kelsie Hibbs sent a header off the crossbar and into the net that knotted the game at 1-all for Morgantown off an assist from senior Payton Southall's corner kick with 15:14 to go in regulation."We lost our fire [the last 10 minutes],'' said Morgantown coach Ashley Neal. "Some people started playing as individuals instead of as a team and let the whole team down. It was heart that was missing.'' WINFIELD 3, B-U 0: Freshman Katie Bryant gave the Generals the lead for good off an assist from Cole about halfway through the opening half. No. 2 Buckhannon-Upshur (22-2) pressured Winfield at the beginning of the second half, but never really put a hard shot on goal. The Generals weathered the storm, then Cole gave them some breathing room with an unassisted tally with 10:15 to go. Jayne Lawman tacked on a goal with 12 seconds remaining."Our hearts were racing and you get nervous because we've been waiting over a week,'' Cole said. "I think the first goal just set the tone and we had it from there.''Winfield senior keeper Faith Burchett made six saves, including several early in the second half when the Bucs were on the attack.Senior goalie Kelsey Hinzman kept the Bucs in the game with several dazzling stops and finished with 11 saves."I think we were outplayed,'' said B-U coach Tom Hasbrouck. "They're better than us today. I just had a great group of seniors. About 12 minutes in I said to my assistant coach, 'They're playing like they've been here before. We're playing like we haven't.' I thought we were very tentative the first 25 minutes or so.''Boys HURRICANE 4, HEDGES-VILLE 0: It didn't take long for the Redskins to take control as senior Felipe Thompson, a foreign-exchange student from Chile, connected about three minutes into the opening half. Hurricane seniors Daniel McKnight and Alex White followed with one goal apiece before halftime then senior Trevor Cunningham tallied the final one in the second half. Keeper Tim Hayslett stopped four shots.Senior goalie Ethan Waters turned in six saves for No. 16 Hedgesville (14-7-1), which upset No. 7 Martinsburg and No. 10 Washington in sectional and regional play. PARKERSBURG 1, GW 0: Senior Garrett Kruger netted a goal late in the first half and the Big Reds made it stand up behind junior keeper Reid Strobl's two saves. It appeared the No. 5 Patriots (16-6-2) knotted the game at 1-all with 19:38 left in the second half, but the referee waved off the goal.GW's Drew Davis was awarded a kick from about 30 yards away and sent it over the defensive wall and Strobl's outstretched arms and into the goal, touching off a celebration. The ref then ruled that the kick was an indirect and the ball must touch another player before going in the net to count as a goal.Garrett Phillips made two saves for the Patriots, which lost seven starters from last year's team to graduation.Reach Tommy R. Atkinson at firstname.lastname@example.com or 304-348-4811. Story Share Story Share Trending Now 1 Innerviews: Dual-identity surgeon riding high in horse racing world 2 Former State Police captain now chief in Winfield 3 Huggins, WVU tap South Florida hoops talent 4 WVU seeking improvements during off week 5 Man charged after motorcycle pursuit early Sunday State soccer tournament results, pairings, boxes Previous Story Notes: Short-handed no more, Polar Bears pepper net Next Story