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 efcient 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;

Transformation;
I.
INTRODUCTION
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 developers 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 efcient 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 specic
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.
II.
RESEARCH METHODOLOGY
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).

III.
PROBLEM STATEMENT
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

The term DevOps is not all around characterized, and you'd

be unable to get a similar meaning of "DevOps" from
everybody you ask in your endeavor. Engineers in your
association may compare DevOps with a particular way to deal
with programming constructs and the utilization of prominent
instruments, for example, Chef, Puppet, Jenkins, Git, and
Docker. IT administration may consider DevOps to be a
continuation of existing procedures with an accentuation on
speedier time to market and lightweight discharge methods.

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.

Without a typical meaning of the term you'll have groups

contending over what is DevOps and what is not DevOps. On
the off chance that your product discharges still include the
utilization of a change administration device, for example,
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. Venture
DevOps is bargain between self-benefit, fast fire nimbleness
and the capacity to deal with the dangers that go with missionbasic forms.

We've seen various organizations embrace DevOps, move to

quicker, 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. 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.

Some of our clients are propelling rockets and running

economies, "DevOps" implies something altogether different to
these customers than it intends to a start up.
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, generally
essentially,
Where do you draw the limits amongst DevOps and more
organized ways to deal with IT benefit administration.
Neglect to do this and you'll see groups contending over
what DevOps "is."

Focus on tools and techniques, forget about people.

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. It isn't sufficient
to employ a couple discharge engineers, give them a pack of
VMs, and consent to introduce Jenkins and Puppet. 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.
Rather what you have to guarantee in any DevOps activity is
that you are taking human-driven procedures in record. You

You can simply make more situations by tossing servers at the

issue, yet it's improbable to anticipate that your groups will
scale overnight. Every so often, your QA group needs to rest.

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. 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 various us have taken an interest in these
moves in the course of the most recent decade. You work for an
organization that has enormous framework, obstinate
discharges that take months, and, in the long run, you simply
lose persistence with the procedure and maybe a couple groups
conclude that they will think outside the box and move rapidly.
The principal DevOps were breaking the principles by plan.
They were included autonomous groups "allowed to enhance"
outside of unified IT structures. This approach works in littler
new businesses, however it is a non-starter in many
undertakings.
A venture without regular norms for programming engineering,
discharge administration, and environment administration isn't
an undertaking by any stretch of the imagination it's a terrible
wreckage.
An association with many autonomous groups making novel
consistent organization pipelines sounds great in a work of
DevOps fiction, yet it never works by and by. When we work
with the biggest organizations in the business they need to
empower groups to work speedier, however they likewise
comprehend that DevOps isn't about diminishing the quantity
of administration doors. Despite what might be expected, in the
event that anything DevOps empowers more viable, more
incessant administration entryways on the off chance that you

utilize a device like Plutora to sparkle a light on complex

discharge organization challenges.

Fail to account for risk

DevOps devices and systems more than a few quarters. 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.
Endeavors hope to see hard information to go down staffing
and foundation choices. 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.

More regular discharges, self-benefit provisioning of

foundation, framework computerization, constant conveyance
pipelines: these basic components of DevOps activities prompt
to quicker time to showcase, however at the last part of a
discharge procedure the business dangers stay unaltered.
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.

On the off chance that you stand up a DevOps group request

that they characterize parts and obligations. Consider them
responsible for conveying more prominent productivity to the
association. Routinely check in with designers and framework
chairmen not on the group and equitably evaluate the
outcomes. 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.

Many organizations make a plunge into DevOps without a full

comprehension of how DevOps will influence dangers
connected with programming discharges. At the point when an
organization moves from a slower, ITIL-centered procedure to
a more coordinated, DevOps-centered reality discharge
directors are regularly anticipated that would "wing it" at the
end of the discharge cycle. They are requested that put
administration entryways on a quick moving, always advancing
procedure that is driven by advancement groups anxious to
discharge.

Discussion
Demonstrate changes assume a key part in various spaces, for
example, display driven structures and model-driven
improvement [27]. 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. (ii) Alternatively, a middle representation can
be utilized to render models in a broadly useful markup dialect,
for example, XML. (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. Programming can be conveyed speedier, however the
undertaking still require administration doors.
With Plutora you can let application advancement groups move
rapidly, you can permit groups to lead various concurrent
discharge, 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. 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.

Run DevOps without metrics

DevOps groups begin exceptionally anxious to roll out vast
improvements to a venture's framework and discharge handle,
yet they additionally tend to gnaw off more than they can bite.
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. In our work we concentrate on the transitional

representation of changed models based TOSCA and rendered
in XML. In this paper we were for the most part concentrating
on the demonstrating a portion of Cloud applications in view of
TOSCA. Related work [23], [29] presents ways to deal with
send and oversee Cloud applications that are demonstrated in
light of TOSCA and our change system. There are a few
contrasting options to TOSCA, for example, CloudML [30],
Blueprints [31], and venture topology charts [32]. Also, design
based arrangement approaches [33] use a restrictive meta
display in light of Chef to change examples to deployable
curios. Since TOSCA is a rising standard and tooling backing is
enhancing too, we chose to utilize TOSCA as an interoperable,
middle of the road meta display. Advance organization
methodologies are starting in the DevOps people group, for
example, Amazon OpsWorks [34], Terraform21, and
DevOpSlang [35]. These can be used to organize the changed
ancient rarities in a more consistent and interoperable way.
Notwithstanding unadulterated organization computerization
approaches that are essentially focusing on the level of
foundation as-an administration, diverse stage as-aservice
(PaaS) structures and arrangements are rising, for example,

Heroku22, IBM Bluemix23, and Cloud Foundry24. These

empower the bundling of middleware and application segments
on a more elevated amount, generally abstracting ceaselessly
foundation perspectives, for example, virtual servers and
systems administration. Thusly, ancient rarities that are bundled
along these lines can be considered as environment-driven
antiquities. Comparing change ideas talked about in this paper
might be exchanged to these sorts of antiquities.

Conclusions
The DevOps worldview is ascending in noticeable quality in
contemporary data frameworks as the methods for efcient,
consistent
end-to-end
computerized
programming
administration. The blend of DevOps methodologies with
Cloud figuring arrangements empowers the fast provisioning of
framework assets on request. 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. Be that as it may,
choosing how to utilize this learning is upset by the large
number of existing methodologies, the disseminating of
information between various groups and specialists, and the
width of the accessible plan space in application outline.
Keeping in mind the end goal to address the requirement for
educated basic leadership, in the past segments we displayed
our proposition for an all-encompassing DevOps learning
administration strategy. All the more specically, we identied
an arrangement of information sources that can be (openly)
gotten to, and the way to reap the learning that is contained in
these sources. This should be possible in a mechanized way in
light of our slithering methodology. At long last, we talked
about how to reect, compose, store, and use the information
utilizing a DevOps knowledgebase, predicate rationale, and
WS-Policy. Future work incorporates the change of the
learning administration approach by populating the DevOps
KB with more offerings from Cloud suppliers, the assessment
of creeping methods for the programmed catching of such
offerings, The DevOps worldview is ascending in noticeable
quality in contemporary data frameworks as the methods for
efcient, consistent end-to-end robotized programming
administration. The blend of DevOps methodologies with
Cloud figuring arrangements empowers the quick provisioning
of framework assets on request. 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. In any case, choosing
how to utilize this information is obstructed by the huge
number of existing met

REFERENCES
[1] J. Humble and D. Farley, Continuous Delivery: Reliable Software Releases
through Build, Test, and Deployment Automation. AddisonWesley
Professional, 2010.

[2] J. Humble and J. Molesky, Why Enterprises Must Adopt Devops to

Enable Continuous Delivery, Cutter IT Journal, vol. 24, 2011.
[3] M. Walls, Building a DevOps Culture. OReilly Media, Inc., 2013.
[4] J. Wettinger, U. Breitenbucher, and F. Leymann, DevOpSlang - Bridging
the Gap Between Development and Operations, in Proceedings of the 3rd
European Conference on Service-Oriented and Cloud Computing (ESOCC),
2014.
[5] M. Huttermann, DevOps for Developers. Apress, 2012.
[6] S. Nelson-Smith, Test-Driven Infrastructure with Chef. OReilly Media,
Inc., 2013.
[7] S. Gunther, M. Haupt, and M. Splieth, Utilizing Internal DomainSpecic
Languages for Deployment and Maintenance of IT Infrastructures, Very Large
Business Applications Lab Magdeburg, Fakultat f ur Informatik, Otto-vonGuericke-Universitat Magdeburg, Tech. Rep., 2010.
[8] J. Turnbull and J. McCune, Pro Puppet. Apress, 2011.
[9] T. Uphill, Mastering Puppet. Packt Publishing Ltd, 2014.
[10] P. Mell and T. Grance, The NIST Denition of Cloud Computing,
National Institute of Standards and Technology, 2011.
[11] S. Kachele, F. J. Hauck, C. Spann, and J. Domaschka, Beyond IaaS and
PaaS: An Extended Cloud Taxonomy for Computation, Storage and
Networking, 2013.
[12] P. Trinkle, An Introduction to Unsupervised Document Classication,
2009.
[13] S. Dustdar and K. Bhattacharya, The Social Compute Unit, Internet
Computing, IEEE, vol. 15, no. 3, pp. 6469, 2011.
[14] W3C, Web Services Policy Framework (WS-Policy), Version 1.5, 2007.
[15] V. Andrikopoulos, S. G. Saez, F. Leymann, and J. Wettinger, Optimal
Distribution of Applications in the Cloud, in Proceedings of the 26th
Conference on Advanced Information Systems Engineering (CAiSE), ser.
LNCS. Springer, 2014, pp. 7590.
[16] K. Pepple, Deploying OpenStack. OReilly Media, 2011.
[17] OASIS, Topology and Orchestration Specication for Cloud
Applications (TOSCA) Primer Version 1.0, 2013. [Online]. Available:
http://docs.oasis-open.org/tosca/tosca-primer/v1.0/cnd01/ tosca-primerv1.0-cnd01.html
[18] , Web Services Business Process Execution Language (BPEL)
Version 2.0, 2007.
[19] OMG, Business Process Model and Notation (BPMN) Version 2.0,
2011.
[20] O. Kopp, T. Binz, U. Breitenbucher, and F. Leymann, BPMN4TOSCA:
A Domain-Specic Language to Model Management Plans for
Composite Applications, in Business Process Model and Notation, ser.
Lecture Notes in Business Information Processing, J. Mendling and M.
Weidlich, Eds., vol. 125. Springer Berlin Heidelberg, 2012, pp. 3852.
[21] O. Kopp, T. Binz, U. Breitenbucher, and F. Leymann, Winery - A
Modeling Tool for TOSCA-based Cloud Applications, in Proceedings of the
11th International Conference on Service-Oriented Computing, ser. LNCS, vol.
8274. Springer Berlin Heidelberg, 2013, pp. 702706.
[22] T. Binz, U. Breitenbucher, F. Haupt, O. Kopp, F. Leymann, A. Nowak,
and S. Wagner, OpenTOSCA a runtime for TOSCA-based cloud
applications, in Proceedings of the 11th International Conference on ServiceOriented Computing, ser. LNCS. Springer, 2013.
[23] J. Wettinger, M. Behrendt, T. Binz, U. Breitenbucher, G. Breiter, F.
Leymann, S. Moser, I. Schwertle, and T. Spatzier, Integrating Conguration
Management with Model-Driven Cloud Management Based on TOSCA, in
Proceedings of the 3rd International Conference on Cloud Computing and
Services Science. SciTePress, 2013.
[24] J. Loope, Managing Infrastructure with Puppet. OReilly Media, Inc.,
2011.
[25] D. Zamboni, Learning CFEngine 3: Automated System Administration for
Sites of Any Size. OReilly Media, Inc., 2012
. [26] U. Breitenbucher, T. Binz, O. Kopp, and F. Leymann, Vinothek - A
Self-Service Portal for TOSCA, in ZEUS. CEUR-WS.org, 2014, ESOCC),
2014pp. 6972. [27] A. Kleppe, J. Warmer, and W. Bast, MDA Explained The Model Driven Architecture: Practice and Promise, 2003.
[28] S. Sendall and W. Kozaczynski, Model Transformation the Heart and
Soul of Model-Driven Software Development, Tech. Rep., 2003.

[29] J. Wettinger, T. Binz, U. Breitenbucher, O. Kopp, F. Leymann, and M.

Zimmermann, Unied Invocation of Scripts and Services for Provisioning,
Deployment, and Management of Cloud Applications Based on TOSCA, in
Proceedings of the 4th International Conference on Cloud Computing and
Services Science. SciTePress, 2014.
[30] A. Rossini, N. Nikolov, D. Romero, J. Domaschka, K. Kritikos, T.
Kirkham, and A. Solberg, CloudML Implementation Documentation,
PaaSage project deliverable, 2014.

[31] M. Papazoglou and W. van den Heuvel, Blueprinting the Cloud, Internet
Computing, IEEE, vol. 15, no. 6, pp. 7479, 2011.
[32] T. Binz, C. Fehling, F. Leymann, A. Nowak, and D. Schumm,
Formalizing the Cloud through Enterprise Topology Graphs, in Proceedings
of the IEEE International Conference on Cloud Computing. IEEE Computer
Society Conference Publishing Services, 2012.
[33] H. Lu, M. Shtern, B. Simmons, M. Smit, and M. Litoiu, Pattern-based
Deployment Service for Next Generation Clouds, 2013.
[34] T. Rosner, Learning AWS OpsWorks. Packt Publishing Ltd, 2013.

[35] J. Wettinger, U. Breitenbucher, and F. Leymann,

DevOpSlang - Bridging the Gap Between Development and
Operations, in Proceedings of the 3rd European Conference
on Service-Oriented and