-
Notifications
You must be signed in to change notification settings - Fork 0
/
use-cases.html
executable file
·314 lines (309 loc) · 15.1 KB
/
use-cases.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en">
<head>
<meta charset="utf-8" name="viewport" content="width=device-width, initial-scale=1">
<title>Ocopea - Use Cases</title>
<link href="https://fonts.googleapis.com/css?family=Open+Sans" rel="stylesheet">
<link href="https://fonts.googleapis.com/css?family=Mukta+Vaani:400,700,800" rel="stylesheet">
<link rel="stylesheet" type="text/css" href="style.css">
</head>
<body>
<main>
<header>
<div class="content">
<div class="main-navigation">
<img src="assets/-e-LOGO_big.png" alt="" class="logo"/>
<ul class="main-navigation-list">
<li><a href="index.html">about</a></li>
<li class="selected"><a href="#">use cases</a></li>
<li><a href="how-it-works.html">how it works</a></li>
<li><a href="http://ocopea-documentation.readthedocs.io/en/latest/">documentation</a></li>
</ul>
</div> <!-- ./main-navigation -->
<div class="title-container" style="height: 500px">
<div class="title">
<div>Ocopea</div>
<div>Use Cases</div>
</div>
</div>
</div> <!-- ./content -->
</header>
<div class="use-case-page">
<div class="content">
<div class="title">
Developer Copies
</div>
<p>
Effective use of application copies can boost the development process agility and product quality. With a
microservices architecture this becomes even more critical as applications tend to have
many small databases. Ocopea comes to the rescue and makes the developer's life simpler by
enabling application copy re-purposing into developer workflows and tools.
</p>
<br/>
<p>
Let's walk through some of the scenarios using the Ocopea UI.
</p>
<br/>
<br/>
<div class="title">
Bug fixing
</div>
<div style="text-align: center">
<iframe width="560" height="315" src="https://www.youtube.com/embed/AUf76WdcM7Q" frameborder="0" allowfullscreen></iframe>
</div>
<br/>
<br/>
<p>
I am testing the latest version of my organization's app named Lets-chat.
Lets-chat is a chat app that uses MongoDB to store all of its data.
Today I managed to reproduce a sneaky rare bug that is very annoying to customers.
Excited with my success, I plan on sending the mail to the entire organization saying:
Don't touch this cluster until a developer reviews the bug and fixes it!
Then I plan to leave the app running, and go have a snack as my environment is pending.
<br/>
<br/>
Oh.. Copy.. but I have Ocopea!
<br/>
<br/>
With Ocopea it is simpler than ever to freeze application state and transfer it between engineers.
All we have to do is simply create a "saved application image" and share it.
<br/>
<br/>
</p>
<div class="image-holder">
<img src="assets/save-image-button.png" width="600px" alt="create saved image" />
</div>
<br/>
<br/>
<p>
When creating the image, users name it, label it, and add comments so that it will be easy to
locate in the future.
</p>
<br/>
<br/>
<div class="image-holder">
<img src="assets/save-image-dialog.png" width="400px" alt="supply image metadata" />
</div>
<br/>
<br/>
<p>
In the background, Ocopea orchestration kicks in and creates a copy of all the components involved
in running the app: Container versions, Kubernetes deployment configuration
and a physical copy of all data services involved - in our case one instance of MongoDB.
Copies are stored on a copy repository configured by the user.
<br/>
<br/>
Once the image is persisted it is stored in the Ocopea image catalog and can be shared with
other team members.
</p>
<br/>
<br/>
<div class="image-holder">
<img src="assets/got-it.png" width="700px">
</div>
<br/>
<br/>
<div class="image-holder">
<img src="assets/share-image.png" width="400px">
</div>
<br/>
<br/>
<p>
Restoring the Ocopea image is as easy as creating it and can be done with a click. Developers
can restore the images to their own environment for debugging purpose.
</p>
<br/>
<p>
Ocopea supports several bug tracking tools, but it can be extended to integrate with anything.
</p>
<br/>
<br/>
<div class="title">
Agile process
</div>
<p>
Modern engineering groups are using some sort of process to manage the
deployments of cloud native apps. With short iterations, and frequent deployments -
the ability to have a rolling application instance with fresh and relevant data can improve the
process and boost quality and productivity.
</p>
<br/>
<br/>
<p>
Ocopea's saved images fits perfectly into this process by allowing developers and other stake holders
to store and share application in specific states.
Product owners for example, can use a customer database and manipulate it with data so that developers
at the end of the sprint could demo the features using a pre-defined application instance with enough
data to cover the use case. Developers can always pick an image pre-loaded with large quantities of
data in order to demonstrate how new features do not degrade the app performance.
App images can be used by everyone in the org to demo the latest state of the app - all with relevant
data populated and up-to-date.
</p>
<br/>
<br/>
<div class="image-holder">
<img src="assets/choose-image.png" width="664">
</div>
<br/>
<br/>
<p>
When a developer uses the Ocopea UI in order to run a new copy of the app he can choose to populate
the application instance with data using one of these options:
</p>
<ul class="list">
<li>Blank - run the app with empty initialized schemas</li>
<li>Saved Image - populate data using one of the images from the Ocopea saved images catalog</li>
</ul>
<br/>
<p>
Once an image is created, developers can choose target cluster/site to be used. Ocopea will present
only sites that can support the deployment. for example - if the application has an S3 dependency,
only sites that support that can be used (AWS S3, minio on premises etc.). In addition, Ocopea
will let you select the service plan to be used. This is useful since for most cases - test and dev
can use service plans with reduced SLA.
</p>
<br/>
<br/>
<div class="image-holder">
<img src="assets/deployment-config.png" alt="selecting service plans"/>
</div>
<br/>
<br/>
<p>
By default Ocopea will configure the application exactly the same as it was when the copy was
made. Users can, however, make changes to the configuration, for example, by changing some of the
component versions or even creating partial deployments - all according to what is needed.
Ocopea integrates with public and private docker registries and maven repositories allowing the user
to pick from the latest images available.
</p>
<br/>
<br/>
<div class="image-holder">
<!--suppress CheckImageSize -->
<img src="assets/configure-hackathon.png" width="664px" alt="app instance configuration" />
</div>
<br/>
<br/>
<p>
Having the ability to provision a full running app including its data with a single click
is huge deal for developers. This replaces the process of going though ops to provision the instances,
asking the backup admin to restore the data, coordinating with DBAs to install the database binaries
and finally deploying the application and configuring it to use the restored services.
If developers used to think twice before validating their fixes with various sets of data from
production systems - with Ocopea - there is no hesitation!
</p>
<br/>
<br/>
<div class="title">
Automated tests
</div>
<p>
When deploying to production frequently, automated tests are critical. A big weak point of
automated tests has always been the way it generates application data. When trying to run a system
level test that involves more than one service there are several ways to generate data for the tests.
To name a few:
</p>
<ul class="list">
<li>
Starting from scratch and generating data through the application API
</li>
<li>
Each service runs database scripts to load data
</li>
<li>
Using a dedicated production copy environment cluster and cleaning up afterward
</li>
</ul>
<br/>
<p>
All methods have caveats and usually result in insufficient test quality,
testing against schemas that are not up-to-date and/or having a messy process of maintaining
historical upgraded instances.
</p>
<br/>
<br/>
<p>
Ocopea offers a different path. Using the Ocopea API, developers can insert Ocopea into the CI/CD
pipeline and use it to orchestrate up-to-date application copies with various sets of pre-defined
data sets. Not only will test quality improve, it will also
allow developers to debug failing tests on their own environment with identical data. Developers
can now easily add new test use cases based on production data that can be re-executed on every build.
Instead of maintaining upgradable test instances, there is only one schema upgrade process - the one
used in production is also used in tests.
</p>
<br/>
<br/>
<div class="title">
Increase Resource Usage Visibility
</div>
<p>
Cloud native platforms simplify deployments by using shared infrastructure among developers.
If in the past developers used their own VMs to do development and debugging,
with cloud native they simply deployed their instances into a shared cluster.
While this simplifies the lives of developers, it can also easily lead to resource over-utilization and
lack of visibility into what the resources are being used for.
Without visibility into the entire application deployment and its usage
- it is difficult to make sense of what is going on out there in the services zoo.
Allowing drill-down into which services are being used by developers can lead to significant
cost reduction.
</p>
<br/>
<br/>
<p>
In our vision we see application-centric quota management. Implementing this requires standardization
of the service consumption API so we can calculate usage of an application consisting of stateless
services side by side managed SaaS services. Please join us in our
<a href="standardization.html">call for action for standardization</a>.
</p>
<br/>
<br/>
<div class="image-holder">
<!--suppress CheckImageSize -->
<img src="assets/app-centric-quota.png" width="800px" alt="app instance configuration" />
</div>
<br/>
<br/>
<p>
In the mean time Ocopea can still display application centric usage metrics and can be used
to get better visibility into the application clusters.
</p>
<br/>
<br/>
<div class="title">
Safe upgrade process
</div>
<p>
With modern software, the more one can automate - the better. That said, at least for now -
our business application code is still being typed by human developers.
With frequent deployments to production, errors in production is only a matter of time.
Ocopea allows developers to hook into the application copy orchestrator via API and make application
copy before each upgrade and perform tests with latest code on fresh production data.
</p>
<br/>
<br/>
<br/>
<br/>
</div>
<footer>
<div class="content">
<div class="logo">
<img src="assets/-e-LOGO_big.png" alt=""/>
</div>
<div class="address">
<p>
</p>
<p><a href="https://ocopea.github.io">ocopea.github.io</a></p>
</div>
<div class="icons">
<a href="https://codecommunity.slack.com/archives/ocopea"><img src="assets/slack.png" alt=""></a>
<a href="https://github.com/ocopea"><img src="assets/github.png" alt=""></a>
<img src="assets/blogger.png" alt="">
<a href="https://twitter.com/ocopea"><img src="assets/twitter.png" alt=""/></a>
</div>
<div class="copyrights">Copyright © 2017 Dell Inc. or its subsidiaries. All Rights Reserved</div>
</div>
</footer>
</main>
</body>
</html>