You are on page 1of 7

Five Pitfalls of DevOps in Industry

Abstract— DevOps is a rising worldview to effectively encourage
the cooperation between framework designers and operations
keeping in mind the end goal to empower efficient end-to-end
robotization of programming sending and administration forms.
DevOps is ordinarily consolidated with Cloud registering, which
empowers quick, on-request provisioning of basic assets, for
example, virtual servers, stockpiling, or database occurrences
utilizing APIs as a part of a self-benefit way. Today, a continually
developing measure of DevOps devices, reusable ancient rarities,
for example, scripts, and Cloud administrations are accessible to
execute DevOps robotization. Accordingly, educated basic
leadership on the fitting approach(es) for the necessities of an
application is hard. In this work we introduce a community
oriented and all encompassing way to deal with catch DevOps
learning in a knowledgebase. Adjacent to the capacity to catch
master information and use crowdsourcing approaches, we
actualized a creeping structure to naturally find and catch
DevOps learning. Also, we indicate how this information is used to
convey and work Cloud applications.
Keywords— DevOps; Deployment Automation;

DevOps integrates developers and operations teams in order to
improve collaboration and productivity by automating
infrastructure, automating workflows and continuously
measuring application performance. DevOps teams place more
focus on automation, they try to automate everything from
testing of new code to how infrastructure has provisioned.
DevOps team write software in small chunks that are
integrated, tested, monitored and deployed usually in hours
versus traditional way of writing large chunks of software over
weeks or months and then do weeks and months of testing
.Furthermore they have identical development environment and
production environment based on same configurations.
Writing small chunks of code will allow them to increase
frequency of deployments and improve time to deploy new
code. It also enables them to adopt an interactive process to
monitor ,measure and improve the code and operations
everyday improve their ability to respond to market needs or
other things impact software.
DevOps is being used in industries from quiet sometime to fill
the gap between developer’s team and operations team in order
to produce higher-quality code faster with less time available
for QA. Where there are many success stories of using DevOps
in industries they are few Industries which have failed using
DevOps In this paper, I have highlighted some of the pitfalls
large organizations need to take into account before they board
on their agile transformation journey.
DevOps methodologies are commonly consolidated with Cloud
registering [10] to empower on-request provisioning of assets,
for example, virtual servers and capacity in a self-benefit way.
Diverse interfaces are offered by Cloud suppliers (e.g.,
Amazon6, for example, graphical UIs, order line interfaces, and

APIs to arrangement and deal with these assets. Particularly
APIs and charge line interfaces are an efficient intends to
coordinate DevOps computerization approaches with Cloud
asset administration automatically. This should be possible for
open, private, and half and half Cloud situations. For instance,
Amazon's APIs can be used to arrangement virtual servers on
which Chef cook books or Juju charms are executed to convey
a specific application stack. In addition, some Cloud suppliers
offer higher level administrations, for example, middleware
administrations (e.g., runtime-as-a service, database-as-an
administration, and so on.) and operations robotization
administrations, abstracting from the hidden framework. These
administrations can be utilized on the other hand or
corresponding to the lower-level framework administrations.
Since DevOps robotization methodologies and Cloud
administrations show up, change, and vanish quickly, it is
difficult to pick the most fitting arrangements and blends
thereof to implement holistic DevOps automation for a specific
application. Educated basic leadership is hard in view of the
enormous assortment of alternatives. DevOps information is for
all intents and purposes accessible everywhere scale, except it
is not efficiently caught and oversaw.
The purpose of a literature review is to enable researchers to
map and analyse the significant literature published on a topic
and to establish a particular issue for its deep investigation. An
alternative to literature review is its systematic review. The
systematic literature review is a methodology that uses relevant
literature to a particular issue as data source providing a
selection, critical contribution evaluation, analysis, and
summary of each work. It describes the evidences leading to
reasonable conclusions about what is known and not known
about the topic (Denyer and Tranfield, 2009).

In this paper we focus on some of the pitfalls that are
contributing to a failed DevOps initiative – a DevOps initiative
that often ends up being either abandoned or one that ultimately
ends up recreating the same messy bureaucracy it was
supposed to replace.
Following are the five pitfalls.
Fail to define what DevOps means to your organization

" Focus on tools and techniques. generally essentially. and Docker. Chef. Without a typical meaning of the term you'll have groups contending over what is DevOps and what is not DevOps. Neglect to do this and you'll see groups contending over what DevOps "is. yet it's improbable to anticipate that your groups will scale overnight. and. They were included autonomous groups "allowed to enhance" outside of unified IT structures. and various us have taken an interest in these moves in the course of the most recent decade. DevOps in the endeavor has a tendency to rise up out of maybe a couple gather choosing to arrange an upset against an incapable IT association. and environment administration isn't an undertaking by any stretch of the imagination – it's a terrible wreckage. obstinate discharges that take months.The term DevOps is not all around characterized. IT administration may consider DevOps to be a continuation of existing procedures with an accentuation on speedier time to market and lightweight discharge methods. Despite what might be expected. The oversight many endeavors make is to hoist innovation as the essential driver of DevOps to the detriment of a portion of the troublesome yet fundamental procedures that guarantee that quality programming that meets client desires. forget about people. your QA group needs to rest. "DevOps" implies something altogether different to these customers than it intends to a start up. in the long run. Git. An association with many autonomous groups making novel consistent organization pipelines sounds great in a work of DevOps fiction. This approach works in littler new businesses. more continuous discharges driven by the requirements of individual ventures just to understand that an expansion rhythm of programming conveyance can prompt to QA and discharge administration burnout. for example. discharge administration. in the event that anything DevOps empowers more viable. Jenkins. Some of our clients are propelling rockets and running economies. Venture DevOps is bargain between self-benefit. You can't simply employ a group of "DevOps People" place them in a room and step away anticipating that them should work "Enchantment" and make everything more effective. fast fire nimbleness and the capacity to deal with the dangers that go with missionbasic forms. On the off chance that your product discharges still include the utilization of a change administration device. give them a pack of VMs. You You can simply make more situations by tossing servers at the issue. On the off chance that you are acquainting more robotization with speed time to market ensure you likewise think about the effect any DevOps activity will have on individuals. It isn't sufficient to employ a couple discharge engineers. BMC's Remedy is it truly DevOps? On the off chance that the assemble takes a hour to send a QA fabricate is it truly DevOps? The truth of Enterprise DevOps is that each association's responses to these question will change. Where do you draw the limits amongst DevOps and more organized ways to deal with IT benefit administration. A venture without regular norms for programming engineering. more incessant administration entryways on the off chance that you . move to quicker. you simply lose persistence with the procedure and maybe a couple groups conclude that they will think outside the box and move rapidly. for example. Every so often. The principal DevOps were breaking the principles by plan. Engineers in your association may compare DevOps with a particular way to deal with programming constructs and the utilization of prominent instruments. Ignore governance entirely A considerable measure of the talk for DevOps is established in the possibility that engineers need to adopt a proactive strategy to "course around" change-opposed managers. We've seen various organizations embrace DevOps. You work for an organization that has enormous framework. When we work with the biggest organizations in the business they need to empower groups to work speedier. have to adjust any current groups such a quality confirmation and discharge administration with DevOps activities to evade the basic slip-up of neglecting to adjust a current undertaking discharge administration procedure to another way to deal with programming conveyance and administration. however they likewise comprehend that DevOps isn't about diminishing the quantity of administration doors. yet it never works by and by. and consent to introduce Jenkins and Puppet. Rather what you have to guarantee in any DevOps activity is that you are taking human-driven procedures in record. Before you begin presenting innovation and process under a DevOps activity make a point to characterize a benchmark for your DevOps activity: What is your meaning of DevOps? What are you attempting to achieve? Furthermore. and you'd be unable to get a similar meaning of "DevOps" from everybody you ask in your endeavor. however it is a non-starter in many undertakings. Puppet.

On the off chance that you simply toss engineers at your creation servers you'll learn direct how solid generation is the point at which nobody components hazard in choices about creation. Since TOSCA is a rising standard and tooling backing is enhancing too. ITIL-centered procedure to a more coordinated. Changes to generation confronting frameworks still require thorough change administration and when various groups feel enabled to push to creation consistently (or consistently) despite everything you require some discharge administration work following clashes and hazard. More regular discharges. With Plutora you can let application advancement groups move rapidly. Many organizations make a plunge into DevOps without a full comprehension of how DevOps will influence dangers connected with programming discharges. While you DevOps groups will ought to revaluate your discharge procedure overnight you discharge and IT supervisors to characterize measurements to assess whether DevOps activities are a win. In our work we concentrate on the transitional representation of changed models based TOSCA and rendered in XML. display driven structures and model-driven improvement [27]. for example. always advancing procedure that is driven by advancement groups anxious to discharge. middle of the road meta display. DevOps-centered reality discharge directors are regularly anticipated that would "wing it" at the end of the discharge cycle. design based arrangement approaches [33] use a restrictive meta display in light of Chef to change examples to deployable curios. There are a few contrasting options to TOSCA. . XML. Run DevOps without metrics DevOps groups begin exceptionally anxious to roll out vast improvements to a venture's framework and discharge handle. Programming can be conveyed speedier. Amazon OpsWorks [34]. Endeavors hope to see hard information to go down staffing and foundation choices. They are requested that put administration entryways on a quick moving. and at the last part of the procedure you can incorporate with existing ITIL instruments that operations hopes to have set up to track and oversee chance. As indicated by [28] three noteworthy change methodologies can be recognized: (i) the immediate model control is an approach to instantly alter a current source display keeping in mind the end goal to change it to the objective model. constant conveyance pipelines: these basic components of DevOps activities prompt to quicker time to showcase. Related work [23]. Consider them responsible for conveying more prominent productivity to the association. Advance organization methodologies are starting in the DevOps people group. however at the last part of a discharge procedure the business dangers stay unaltered. [29] presents ways to deal with send and oversee Cloud applications that are demonstrated in light of TOSCA and our change system. yet they additionally tend to gnaw off more than they can bite. Also. for example. Terraform21. Fail to account for risk DevOps devices and systems more than a few quarters. diverse stage as-aservice (PaaS) structures and arrangements are rising. self-benefit provisioning of foundation. In the event that you are put resources into the achievement of a DevOps activity ensure that you are gathering insights that legitimize your venture. for example. a middle representation can be utilized to render models in a broadly useful markup dialect. you can permit groups to lead various concurrent discharge. Blueprints [31]. Discussion Demonstrate changes assume a key part in various spaces.utilize a device like Plutora to sparkle a light on complex discharge organization challenges. The savvy venture comprehends that no activity can meddle with continuous programming improvement and discharge administration and they will deal with the ease back move to changes. we chose to utilize TOSCA as an interoperable. Monitor discharge and environment measurements with Plutora for groups that are included with DevOps and groups not included with DevOps and utilize the information Plutora gives to settle on educated choices to dial up or dial down specific activities from your DevOps groups. and venture topology charts [32]. CloudML [30]. for example. In this paper we were for the most part concentrating on the demonstrating a portion of Cloud applications in view of TOSCA. These can be used to organize the changed ancient rarities in a more consistent and interoperable way. (iii) A change dialect giving develops to express and apply changes might be utilized to drive such model At the point when associations embrace DevOps they regularly lose the implicit "balanced governance" that accompanied ITIL. however the undertaking still require administration doors. and DevOpSlang [35]. On the off chance that you stand up a DevOps group request that they characterize parts and obligations. framework computerization. Routinely check in with designers and framework chairmen not on the group and equitably evaluate the outcomes. (ii) Alternatively. for example. At the point when an organization moves from a slower. Notwithstanding unadulterated organization computerization approaches that are essentially focusing on the level of foundation as-an administration.

Be that as it may. in the past segments we displayed our proposition for an all-encompassing DevOps learning administration strategy. The DevOps worldview is ascending in noticeable quality in contemporary data frameworks as the methods for efficient. and the way to reap the learning that is contained in these sources. At long last. A perpetually extending abundance of existing reusable DevOps antiquities and related Cloud administrations implies that application architects and engineers have plentiful open doors for putting attempted and tried DevOps information into practice. generally abstracting ceaselessly foundation perspectives. consistent end-to-end robotized programming administration. we talked about how to reflect. compose. Thusly. IBM Bluemix23. predicate rationale. the assessment of creeping methods for the programmed catching of such offerings. A constantly extending abundance of existing reusable DevOps ancient rarities and related Cloud administrations implies that application originators and engineers have plentiful open doors for putting attempted and tried DevOps information into practice. and WS-Policy. In any case. Comparing change ideas talked about in this paper might be exchanged to these sorts of antiquities. choosing how to utilize this learning is upset by the large number of existing methodologies. consistent end-to-end computerized programming administration. and Cloud Foundry24. Conclusions The DevOps worldview is ascending in noticeable quality in contemporary data frameworks as the methods for efficient. and the width of the accessible plan space in application outline. choosing how to utilize this information is obstructed by the huge number of existing met . Future work incorporates the change of the learning administration approach by populating the DevOps KB with more offerings from Cloud suppliers. This should be possible in a mechanized way in light of our slithering methodology. and use the information utilizing a DevOps knowledgebase. Keeping in mind the end goal to address the requirement for educated basic leadership. All the more specifically. we identified an arrangement of information sources that can be (openly) gotten to. ancient rarities that are bundled along these lines can be considered as environment-driven antiquities. The blend of DevOps methodologies with Cloud figuring arrangements empowers the quick provisioning of framework assets on request. virtual servers and systems administration. store.Heroku22. The blend of DevOps methodologies with Cloud figuring arrangements empowers the fast provisioning of framework assets on request. the disseminating of information between various groups and specialists. These empower the bundling of middleware and application segments on a more elevated amount. for example.

[6] S. IEEE. Mendling and M. pp. [4] J. F. and F. 2011. Springer Berlin Heidelberg. vol. Inc.” in Proceedings of the 26th Conference on Advanced Information Systems Engineering (CAiSE).” Tech.REFERENCES [1] J. Leymann. McCune. Zamboni.” 2007. Leymann. Loope. “Winery . Continuous Delivery: Reliable Software Releases through Build.0-cnd01. LNCS. Turnbull and J. 2012. “Utilizing Internal DomainSpecific Languages for Deployment and Maintenance of IT Infrastructures. Spatzier. Fakult¨at f¨ ur Informatik. Weidlich. Sendall and W. J. Wettinger. “DevOpSlang . 24.” in Proceedings of the 11th International Conference on ServiceOriented Computing.” in Business Process Model and Notation.. F. 2011.A Self-Service Portal for TOSCA. 2011. Apress. 2013. [26] U. Test.. [11] S. DevOps for Developers. pp. ser. 2012. and M. Uphill. Leymann. O’Reilly Media. Learning CFEngine 3: Automated System Administration for Sites of Any Size. [20] 2013. Splieth. C. 2014. [7] S. “Vinothek . Deploying OpenStack. Otto-vonGuericke-Universit¨at Magdeburg. M. and Deployment Automation. 2011.” Cutter IT Journal. “An Introduction to Unsupervised Document Classification. Available: http://docs. Domaschka. “Optimal Distribution of Applications in the Cloud. M. 8274. Inc. [5] M. S´aez. Dustdar and K. O’Reilly Media. ser. Mell and T.oasis-open. and T. [17] OASIS.” in Proceedings of the 3rd European Conference on Service-Oriented and Cloud Computing (ESOCC). [13] S. 2014. O’Reilly Media. [27] A. Molesky. and W. Bast. [12] P. Wettinger. “Web Services Business Process Execution Language (BPEL) Version 2. Wagner. [28] S. Haupt. I. 2010. Building a DevOps Culture. Eds. Haupt.” 2007.. 702–706.” in ZEUS. [24] J. Pepple. U. 38–52. LNCS. 64–69. Springer. Walls. Lecture Notes in Business Information Processing. G. K¨achele. “Web Services Policy Framework (WS-Policy). 2013. Storage and Networking. Packt Publishing Ltd. J. Springer. Farley. F. Kozaczynski. Apress. G¨unther. Rep. Nowak. “Business Process Model and Notation (BPMN) Version 2. U. Leymann. Wettinger. and J. Binz.” National Institute of Standards and Technology. “Integrating Configuration Management with Model-Driven Cloud Management Based on TOSCA. O. 2003. vol. 75–90. [25] D. 2011.. vol. S. Tech. Hauck. CEUR-WS. Kleppe. ESOCC).Bridging the Gap Between Development and Operations. 2013. Binz. 2012 . [10] P. T. Inc. SciTePress. Leymann. 3.0. Breitenb¨ucher. 2014. and J. Inc. 69–72. [9] T. O’Reilly F. “MDA Explained The Model Driven Architecture: Practice and Promise. Kopp. . Version 1. Leymann. Breiter. Andrikopoulos. [22] T. Spann.” Internet Computing. [Online]. Breitenb¨ucher. Bhattacharya. Kopp. Pro Puppet. [15] V.html [18] ——. Kopp.” 2011. [3] M. Breitenb¨ucher.5. Binz. “Model Transformation the Heart and Soul of Model-Driven Software Development.0/cnd01/ tosca-primerv1. “Beyond IaaS and PaaS: An Extended Cloud Taxonomy for Computation. U. vol. J. “BPMN4TOSCA: A Domain-Specific Language to Model Management Plans for Composite Applications. “Topology and Orchestration Specification for Cloud Applications (TOSCA) Primer Version 1. Springer Berlin Heidelberg. Breitenb¨ucher. [2] J. 2011. Warmer. and S. A.. Schwertle. and F.” 2009. Test-Driven Infrastructure with Chef. T. ser. no. F. 2010. [8] J. Humble and D. [19] OMG.0. [16] K.” Very Large Business Applications Lab Magdeburg. 2014pp. [14] W3C. “OpenTOSCA – a runtime for TOSCA-based cloud applications. U. and F. T. “The Social Compute Unit. Nelson-Smith. Mastering Puppet. Kopp. ser. 2014. S. H¨uttermann. and F.A Modeling Tool for TOSCA-based Cloud Applications.” in Proceedings of the 11th International Conference on Service-Oriented Computing. “The NIST Definition of Cloud Computing. Binz. 125. Leymann. Moser. G. 2013. Binz. [21] O. [23] J. LNCS.0. Trinkle. T. Rep. “Why Enterprises Must Adopt Devops to Enable Continuous Delivery. O. U.” 2013.” 2003. O’Reilly Media.. AddisonWesley Professional. pp. 15. Breitenb¨ucher. Humble and J. Behrendt.” 2013. Managing Infrastructure with Puppet. pp. Grance. Breitenb¨ucher.” in Proceedings of the 3rd International Conference on Cloud Computing and Services Science.

Leymann. Smit. D. Kopp. F. and Management of Cloud Applications Based on TOSCA. Lu. T. Wettinger. 2013. T. 2014. Domaschka. Leymann. Fehling. C. “Formalizing the Cloud through Enterprise Topology Graphs. Wettinger.Bridging the Gap Between Development and Operations. O. Papazoglou and W. Rosner. Shtern. “Pattern-based Deployment Service for Next Generation Clouds. Rossini. Nikolov. Deployment. Romero. A. M. vol. Zimmermann. Packt Publishing Ltd. B. Learning AWS OpsWorks. Kirkham. F. Solberg. “Unified Invocation of Scripts and Services for Provisioning. and D. Simmons. [34] T. van den Heuvel. SciTePress. “Blueprinting the Cloud. “CloudML Implementation Documentation. and F. 2011. IEEE Computer Society Conference Publishing Services. U. [32] T.” in Proceedings of the 4th International Conference on Cloud Computing and Services Science. Binz. 2012. Kritikos.” in Proceedings of the IEEE International Conference on Cloud Computing. 6. and M. N. Nowak. Schumm. “DevOpSlang . IEEE. 2014.” Internet Computing.” 2013. no.” in Proceedings of the 3rd European Conference on Service-Oriented and . and M. J. Breitenb¨ucher. Litoiu. [30] A. K. [31] M. [33] H.[29] J. and A. Binz. Breitenb¨ucher. [35] J.” PaaSage project deliverable. 15. pp. M. Leymann. U. 74–79.