-
Notifications
You must be signed in to change notification settings - Fork 0
/
case-study.html
2703 lines (2353 loc) · 107 KB
/
case-study.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
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html data-wf-page="5f71dd169010d6326b65485d">
<head>
<meta charset="utf-8" />
<title>Armada • Case Study</title>
<meta content="width=device-width, initial-scale=1" name="viewport" />
<link href="assets/css/style.css" rel="stylesheet" type="text/css" />
<script
src="https://ajax.googleapis.com/ajax/libs/webfont/1.6.26/webfont.js"
type="text/javascript"
></script>
<link
rel="stylesheet"
href="https://fonts.googleapis.com/css?family=Inter:regular,500,600,700"
media="all"
/>
<script type="text/javascript">
WebFont.load({ google: { families: ['Inter:regular,500,600,700'] } });
</script>
<script type="text/javascript">
!(function (o, c) {
var n = c.documentElement,
t = ' w-mod-';
(n.className += t + 'js'),
('ontouchstart' in o ||
(o.DocumentTouch && c instanceof DocumentTouch)) &&
(n.className += t + 'touch');
})(window, document);
</script>
<link href="assets/logo.png" rel="shortcut icon" type="image/x-icon" />
<link href="assets/logo.png" rel="apple-touch-icon" />
<script
src="https://kit.fontawesome.com/d019875f94.js"
crossorigin="anonymous"
></script>
<meta
name="image"
property="og:image"
content="assets/images/thumbnail.png"
/>
</head>
<body>
<div class="navigation-wrap">
<div
data-collapse="medium"
data-animation="default"
data-duration="400"
role="banner"
class="navigation w-nav"
>
<div class="navigation-container">
<div class="navigation-left">
<a
href="index.html"
aria-current="page"
class="brand w-nav-brand w—current"
aria-label="home"
>
<img src="assets/logo.png" alt="" class="template-logo" />
</a>
<nav role="navigation" class="nav-menu w-nav-menu">
<a href="case-study.html" class="link-block w-inline-block">
<div style="color: var(--primary)">Case Study</div>
</a>
<a href="presentation.html" class="link-block w-inline-block">
<div>Presentation</div>
</a>
<a href="team.html" class="link-block w-inline-block">
<div>The Team</div>
</a>
</nav>
</div>
<div class="navigation-right">
<div class="login-buttons">
<a href="https://github.com/team-armada" target="_blank">
<span style="color: var(--white)">
<i class="fab fa-github fa-lg"></i>
</span>
</a>
</div>
</div>
</div>
<div class="w-nav-overlay" data-wf-ignore="" id="w-nav-overlay-0"></div>
</div>
</div>
<div id="sidebar" class="toc"></div>
<div class="section header">
<article class="container case-study-container">
<div class="hero-text-container">
<h1 class="h1 centered gradient-text">Case Study</h1>
</div>
<div id="case-study">
<br />
<br />
<!-- Section 1 -->
<h2 class="h2">1. Introduction</h2>
<br />
<h3>1.1. What is Armada?</h3>
<p>
Armada is an open-source container orchestration tool that allows
administrators to automate the configuration and deployment of
development environments in the cloud.
</p>
<br />
<p>
Each development environment within Armada exists as a set of
containers that exposes an Integrated Development Environment (IDE)
and all its necessary dependencies to developers via their browsers.
Armada's architecture is self-hosted on an administrator's Amazon
Web Services (AWS) account and is entirely managed from a dashboard
in the browser.
</p>
<br />
<h3>1.2 Understanding the Problem Space</h3>
<p>
Before diving into Armada's feature set, it's important to highlight
the difficulties of setting up and maintaining developer
environments. Common challenges include configuration, dependency
management, and resource availability.
</p>
<figure>
<img
src="assets/config_overload_dep_management_resource_aval.png"
class="case-study-image-small"
alt="Three images representing configuration overload, dependency management, and resource availability."
/>
</figure>
<br />
<h4>1.2.1 Configuration Overload</h4>
<p>
Developers have no shortage of productivity-enhancing tools from
bundlers to compilers to linters to transpilers. These tools support
a diverse set of use cases across an ever-expanding number of
disciplines, often exposing a configuration file for users to
fine-tune settings.
</p>
<br />
<p>
While the flexibility of customizing a tool to address individual
use cases may seem like an ideal solution, repeating this process
across multiple tools can lead to a constellation of fragile
dependencies and lengthen the amount of time that it takes to get
started on a project. Furthermore, some tools offer so much
flexibility that their configuration files can require their own
specialists to decipher, all of which can easily lead to decision
fatigue. Rather than outlining your core feature set, you'll spend a
non-trivial amount of time level-setting your linter and fiddling
with your formatter.
</p>
<br />
<h4>1.2.2 Dependency Management</h4>
<p>
Most applications rely on other publically-available tools,
frameworks, and libraries. Reusing the work of others removes
redundancy from workflows and greatly accelerates the speed with
which software can be developed. However, using these tools comes
with its own set of tradeoffs.
</p>
<br />
<p>
Almost all modern software is constructed in this way, which means
that any project that an engineer might work on will have to contend
not only with its immediate dependencies but also the dependencies
that its dependencies introduce. While package management tools
abstract much of this complexity away, developers are still left to
deal with the fragility that arises from long chains of
dependencies: upgrading a single dependency can break the entire
chain or create a circular dependency.
</p>
<br />
<h4>1.2.3 Resource Availability</h4>
<p>
Depending on the environment you're working in or the type of
application you're attempting to construct, your workflow may
require a significant amount of computational resources (i.e., CPU,
RAM, GPU, etc.).
</p>
<br />
<p>Such tasks include:</p>
<ul>
<li>
Creating virtual environments on your local machine (i.e., VMWare,
Docker, etc.).
</li>
<li>Utilizing compilers and test runners in "watch" mode.</li>
<li>
Running emulation software for specific deployment targets (i.e.,
Android, iOS,watchOS, etc.).
</li>
<li>Compiling complex or large applications.</li>
<li>Running one or more databases.</li>
</ul>
<br />
<p>
These computationally-intensive tasks increase the minimum hardware
requirements needed to be able to do certain kinds of development
work. Unfortunately, this hardware can be expensive, limiting access
to the machines that can perform these tasks.
</p>
<br />
<h3>1.3 Narrowing Our Focus: Education</h3>
<p>
Although these issues are commonplace, they're often most keenly
felt by students just getting started, which means they're
particularly challenging for their instructors as well.
</p>
<figure>
<img
src="assets/students_instructor.png"
class="case-study-image-small"
alt="Three students and an instructor."
/>
</figure>
<br />
<h4>1.3.1 Students</h4>
<p>
For students who are just learning how to build software, the
challenges of setting up a development environment can be
frustrating at best and insurmountable at worst. A new student's
time and effort are better spent on gaining fluency and comfort with
core programming skills, such as being able to write valid code,
understand syntax, efficiently parse error messages, work on the
command line, and read documentation. Furthermore, time and
attention are both finite, and students who have exhausted their
mental resources in the setup phase of a lesson are less likely to
complete the lesson itself.
</p>
<figure>
<img
src="assets/student-struggle.gif"
class="case-study-image-medium"
alt="An animated image of a student learning to code with several questions."
/>
</figure>
<br />
<h4>1.3.2 Instructors</h4>
<p>
From the perspective of those teaching software development,
understanding precisely why a student's development environment
isn't working correctly can be a time-consuming guessing game, and
navigating version conflicts and configuration issues on a
student-by-student basis is neither efficient nor scalable.
</p>
<figure>
<img
src="assets/instructor_challenges.png"
class="case-study-image-small"
alt="An image with multiple icons representing computer issues that instructors face."
/>
</figure>
<br />
<h2 class="h2">2. Supporting Students</h2>
<br />
<h3>2.1 One-by-One</h3>
<p>
In a typical classroom setting, each student's development
environment is their local machine. When issues with dependencies or
configuration arise, the instructor needs to troubleshoot them on
the individual machines where they're appearing. In the best case,
an issue may be so common that the instructor can document how to
resolve the problem and leave said resolution to students. An
alternative is that the instructor can manually intervene to prevent
the issue from arising again. In any event, dealing with the
recurring issues of configuration and dependency management across
many individual machines is burdensome.
</p>
<figure>
<img
src="assets/instructor_options.png"
class="case-study-image-small"
alt="A book representing a manual and an image representing a 1 to 1 relationship."
/>
</figure>
<br />
<h3>2.2 One for All, All for One</h3>
<p>
What if an instructor were able to guarantee that every student had
access to the same hardware and software? Dealing with a single
configuration would significantly reduce the complexity of
supporting a group of students. But, how could this be done?
</p>
<br />
<p>
Rather than purchasing a new computer for every student, an
instructor might consider <strong>virtualization</strong>:
configuring multiple, isolated environments for students all from
one server.
</p>
<br />
<h4>2.2.1 Virtualization</h4>
<figure>
<img
src="assets/virtualization.png"
class="case-study-image-medium"
alt="An large computer being divided into three smaller computers."
/>
</figure>
<p>
According to
<strong
><a
href="https://www.ibm.com/cloud/learn/virtualization-a-complete-guide"
>International Business Machines (IBM)</a
></strong
>, "Virtualization uses software to create an abstraction layer over
computer hardware that allows the hardware elements of a single
computer—processors, memory, storage and more—to be divided into
multiple virtual computers, commonly called virtual machines (VMs).
Each VM runs its own operating system and behaves like an
independent computer, even though it is running on just a portion of
the actual underlying computer hardware." In some instances, the
computer running the virtualized environments is referred to as the
<strong>host</strong> or <strong>host machine</strong>, while the
virtualized environments themselves are referred to as
<strong>guests</strong> or <strong>guest operating systems</strong>.
</p>
<br />
<h4>2.2.2 The Upside</h4>
<p>
One of the key features of virtualization is the ability to create
an <strong>image</strong>, a snapshot of a computer's operating
system, its files, and its overall state. After an image is created,
it can serve as the basis for an arbitrary number of virtual
machines. For instance, an image could contain all of the
prerequisite files, software, and dependencies needed to perform
tasks for a given class. These images could also be used to restore
a given virtual machine to the desired state should something go
awry.
</p>
<figure>
<img
src="assets/images_virtual_machines.png"
class="case-study-image-medium"
alt="An image being applied to 9 individual virtual machines."
/>
</figure>
<br />
<p>
With this approach, an instructor could configure a single,
functional workspace to distribute to each student. If changes or
updates need to be made, the instructor could simply create a new
image, ensuring that solving a configuration problem for a single
student would solve the same configuration problem for all students.
</p>
<br />
<h4>2.2.3 The Downside</h4>
<p>
The prospective overhead in terms of time and money is significant.
The kinds of servers capable of hosting enough VMs for a classroom
of students are not cheap, and managing them becomes a job in and of
itself. Additionally, this is not a scalable solution: adding
capacity means upgrading existing hardware or purchasing new
hardware altogether. The server is also a single point of failure.
If it goes down, no student can access their environment.
</p>
<figure>
<img
src="assets/cost_management_expansion_spof.png"
class="case-study-image-medium"
alt="Various icons indicating cost, management, expansion, and a single point of failure."
/>
</figure>
<br />
<h3>2.3 The Cloud: A Possible Solution</h3>
<p>
An ideal solution would abstract away the problems of hardware
without being cost-prohibitive while ensuring that issues resolved
for one student would be resolved for all students. Fortunately,
modern cloud technologies make such a solution possible. By offering
centrally-managed, virtualized environments to students from the
cloud, it's possible to affordably offer a set of virtual machines
that can be configured and maintained from a single template and
served to an arbitrary number of students.
</p>
<br />
<h2 class="h2">3. Cloud Deployments</h2>
<br />
<h3>3.1 What are Cloud Environments?</h3>
<p>
Cloud environments are a type of third-party service that provides
on-demand access to networking and computational resources. Unlike
on-premises data centers, which require purchasing and configuring
new hardware to expand capacity, cloud environments can easily scale
with demand. To add capacity in a cloud environment, users simply
need to make a request to the cloud provider. In many cases, the
provisioning of capacity can be managed automatically to adjust the
number of resources according to the user's needs.
</p>
<br />
<h3>3.2 A Modular, Replicable Approach</h3>
<p>
In a cloud environment, instructors no longer have to concern
themselves with hardware. They can dedicate their time and attention
to configuring a single environment exactly as they want it before
deploying it as many times as they need.
</p>
<br />
<h3>3.3 A Identifying Inefficiencies</h3>
<p>
This solution has a significant drawback, however, because the
minimum memory and CPU capacity for VMs offered by cloud providers
is still well beyond what most development environments require.
Most of the time students won't use the full capacity of either the
machine's CPU or its memory, which means that instructors are paying
for more resources than they're actually using. For this reason,
many developers opt to further virtualize their environments with
the help of <strong>containers</strong>.
</p>
<figure>
<img
src="assets/memory_cpu_cost.png"
class="case-study-image-small"
alt="Three icons representing memory, CPU, and cost."
/>
</figure>
<br />
<h3>3.4 Containerization</h3>
<figure>
<img
src="assets/memory_cpu_cost_containers.png"
class="case-study-image-medium"
alt="Three icons representing memory, CPU, and cost with an arrow pointing to four containers."
/>
</figure>
<p>
Containers use virtualization but are not fully-fledged virtual
machines on their own. Instead, containers are applications that are
bundled along with their dependencies using software such as Docker.
</p>
<br />
<p>
Rather than virtualizing an entire machine including its hardware
like a VM, containers instead virtualize the OS, allowing them to
stay much lighter-weight than VMs & unaware of the underlying
systems they are running on.
</p>
<br />
<p>
One side effect of this lighter-weight is that containers aren't
meant to persist for long periods of time. Instead, they're designed
to be created, used, and then destroyed. Due to their ephemeral
nature, containers often present unique challenges when attempting
to persist data.
</p>
<br />
<h4>3.4.1 An Aside: Docker</h4>
<p>
Docker is an open-source platform for creating, developing, and
managing containers. Within the Docker ecosystem, container images
are created via a <strong>Dockerfile</strong>. Dockerfiles enable
developers to configure how a container is constructed, including
specifying a base image that can be extended. These images are
consumed by the Docker Engine which is a runtime environment that
enables containers to be run locally on a developer's machine.
</p>
<figure>
<img
src="assets/dockerfile_to_dockerengine.png"
class="case-study-image-medium"
alt="An image representing a sequence of events from creating a dockerfile, making a docker image, and running a docker container on the docker engine."
/>
</figure>
<br />
<h3>3.5 The Challenges of Managing the Cloud</h3>
<figure>
<img
src="assets/octopus.png"
class="case-study-image-medium"
alt="An octopus juggling several shipping containers."
/>
</figure>
<p>
In order for an instructor to take advantage of containerization in
the cloud to create and replicate developer environments, they would
need to do the following:
</p>
<ul>
<li>Choose a cloud provider.</li>
<li>
Learn about the different services available through that provider
or identify an abstracted solution that works across cloud
providers (i.e., Hashicorp's Terraform).
</li>
<li>
Provision and connect the various services needed to create
containerized environments and make them accessible to students.
</li>
<li>
Manage security and permissions to ensure that students (and only
students) have access to what they need.
</li>
<li>
Develop a scalable process to create and destroy these
environments.
</li>
</ul>
<br />
<p>
Performing each of these steps requires a significant amount of
expertise, time, and effort. Fortunately, there are several
commercially-available products that achieve these goals without
requiring the instructor to be a cloud expert.
</p>
<br />
<h2 class="h2">4. Existing Solutions</h2>
<p>
There are a handful of products that abstract away the issues of
creating and managing developer environments at scale within the
cloud. These are Coder, Gitpod, and GitHub Codespaces.
</p>
<figure>
<img
src="assets/existing_solutions.png"
class="case-study-image-small"
alt="Logos for Coder, Gitpod, and GitHub Codespaces."
/>
</figure>
<br />
<h3>4.1 Clarifying Criteria</h3>
<p>
While each of these individual solutions have their own particular
strengths, they also come with their own set of tradeoffs. We
assessed these solutions against several key criteria:
</p>
<figure>
<img
src="assets/criteria.png"
class="case-study-image-medium"
alt="Various images representing ease of setup, ease of use, multi-IDE support, custom templates, the ability to self-host, and cost."
/>
</figure>
<ul>
<li>
<strong>Ease of Setup</strong>: How difficult is it to get a
working copy of this product on your own system?
</li>
<li>
<strong>Ease of Use</strong>: How difficult is it to configure and
use the features offered by this product?
</li>
<li>
<strong>Multi-IDE Support</strong>: Does this product let you
choose which IDE to use (i.e., VS Code, JetBrains, etc.)?
</li>
<li>
<strong>Custom Templates</strong>: Does this product provide the
ability to customize the environment and its dependencies to meet
my needs?
</li>
<li>
<strong>Self-Hostable</strong>: Could you deploy this product on
an architecture of your own?
</li>
<li>
<strong>Cost</strong>: What are the upfront and recurring costs
for a given solution? Do I have to pay a flat price, a price per
user, or is there a tiered system involved?
</li>
</ul>
<br />
<h3>4.2 Tangible Tradeoffs</h3>
<br />
<h4>4.2.1 Coder</h4>
<p>
Coder is light, fast, flexible, and offers all of the core
functionality a developer expects in an IDE. However, getting it up
and running on your own system can be challenging. Whether you're
using their self-hosted platform or their enterprise product,
there's a fair number of obstacles that require manual intervention
creating a higher barrier of entry. That being said, Coder provides
a reasonably priced platform which charges $35 per user per month.
</p>
<br />
<h4>4.2.2 Gitpod</h4>
<p>
Gitpod offers an extensive feature set, and aside from a longer
startup time, it's also quite fast and flexible. Like Coder, the
installation process doesn't always work right out of the box, and
it can be challenging to get a working copy of the free-tier product
on a local machine. The full range of features offered by Gitpod can
make it challenging to configure, making the learning curve rather
steep for all of the bells and whistles that it provides.
</p>
<br />
<h4>4.2.3 GitHub Codespaces</h4>
<p>
Due to its seamless integration with the GitHub platform, GitHub
Codespaces offers an easy-to-use, turnkey experience that allows
developers to get started quickly. However, GitHub Codespaces limits
users to operating only on their platform through the use of an
instance of VS Code. Additionally, the environments provided by
GitHub Codespaces can be customized to meet individual needs, but
the cost of each environment is the most out of any of the available
solutions.
</p>
<br />
<p>
Each of these products stand on their own merit, but it became clear
that there was one thing they all had in common: all three were
designed with a seasoned developer in mind as their end user, and
were largely built to accommodate the needs of enterprises.
</p>
<br />
<p>That's where <strong>Armada</strong> comes in…</p>
<figure>
<img
src="assets/armada-square-glow-logo.png"
class="case-study-image-x-small"
alt="Armada logo."
/>
</figure>
<br />
<h3>4.3 An Education-First Approach</h3>
<p>
We built Armada to provide an easy-to-use, low-cost option that was
tailor-made for the education space.
</p>
<br />
<p>
Some key features which differentiate Armada from existing solutions
include:
</p>
<ul>
<li>
<strong>Target Audience</strong>: Armada was built with education
in mind and aimed to be powerful enough to serve a broad
cross-section of instructors and students without being
technically burdensome.
</li>
<li>
<strong>Ease of Use</strong>: Administrators can easily create and
manage development environments from Armada's UI. After
authenticating, all students need is a link to their environment
to access it via their browsers.
</li>
<li>
<strong>Cost</strong>: Armada's only cost is the cost incurred
from running its underlying resources on the cloud.
</li>
<li>
<strong>System Ownership</strong>: Armada is deployed to an
instructor's own AWS account, allowing them to maintain full
control over the system and the data it generates.
</li>
<li>
<strong>Extensibility</strong>: Armada is fully open-source. Any
sufficiently technical instructor is free to extend the system to
suit their particular needs.
</li>
</ul>
<br />
<p>
Below is a comparison of each product, including their open-source
and paid offerings.
</p>
<figure>
<img
src="assets/solutions_chart.png"
class="case-study-image-medium"
alt="A chart comparing Gitpod, Coder, GitHub Codespaces, and Armada based on the previously defined criteria."
/>
</figure>
<br />
<h2 class="h2">5. Armada</h2>
<br />
<h3>5.1 Recap</h3>
<br />
<h4>5.1.1 Challenges</h4>
<p>
Configuring a development environment presents several challenges,
which include:
</p>
<br />
<h5>For Students</h5>
<ul>
<li>
Knowledge of complicated environment configuration and dependency
management.
</li>
<li>
Access to hardware capable of carrying out common developer tasks
and running supporting software.
</li>
</ul>
<br />
<h5>For Instructors</h5>
<ul>
<li>
Navigating between a compounding number of student hardware
configurations, operating systems, software versions, and
experience levels.
</li>
</ul>
<br />
<h4>5.1.2 Goals</h4>
<p>
In response to these challenges, we developed Armada with the
following goals in mind:
</p>
<ol>
<li>Create easy-to-use development environments for students.</li>
<li>
Make it easy for instructors to manage and deploy development
environments.
</li>
<li>
Provide the ability to scale to meet student and instructor
demand.
</li>
<li>Minimize costs for instructors.</li>
</ol>
<br />
<h3>5.2 But First, A Demo</h3>
<video controls class="case-study-video">
Your browser does not support the <video> tag.
<source
src="assets/edited_file_student_view_converted.mp4"
type="video/mp4"
/>
</video>
<p class="caption">
Instructor Workflow: Adding a Student to Creating Workspaces
</p>
<br />
<br />
<video controls class="case-study-video">
Your browser does not support the <video> tag.
<source src="assets/full_workflow_converted.mp4" type="video/mp4" />
</video>
<p class="caption">
Student Workflow: Signing In and Accessing Workspace
</p>
<br />
<h3>5.3 The Roadmap</h3>
<p>
With this information in hand, there were eight key milestones that
we needed to achieve in order to create, manage, and serve
development environments that instructors and students could make
use of, including:
</p>
<ol>
<li>Containerizing a workspace.</li>
<li>Provisioning cloud infrastructure.</li>
<li>Deploying a single workspace.</li>
<li>Deploying several workspaces.</li>
<li>Accessing workspaces from dedicated URLs.</li>
<li>Persisting workspace data.</li>
<li>
Establishing relationships between user data entities and
providing a user interface for instructors and students.
</li>
<li>Providing user authentication.</li>
</ol>
<br />
<h3>5.4 Containerizing a Workspace: Developing at Scale</h3>
<br />
<h4>5.4.1 Choosing an Environment</h4>
<figure>
<img
src="assets/gitpod_vs_codeserver.png"
class="case-study-image-small"
alt="Two rectangles, each with a logo inside, for Gitpod and Coder representing a container with a coding environment."
/>
</figure>
<p>
Creating the coding environment itself wasn't the primary focus of
building Armada. Fortunately, a number of freely available, open
source solutions already existed.
</p>
<br />
<p>
As mentioned previously, both Gitpod and Coder offer open-source
versions of their paid platforms and products including
containerized versions of VS Code, a popular, open-source code
editor created by Microsoft. These containers bundle VS Code with
its dependencies, exposing it via a network port which can be
accessed from a browser. While either solution could have been used
as the basis for Armada's workspaces, there were significant
tradeoffs for each.
</p>
<br />
<p>
Even in its open-source form, Gitpod offers a number of extensible
configuration and customization features in addition to several
integrations. However, this comes at the cost of both speed and
size. At the time of Armada's initial build, Gitpod's container was
roughly 7 gigabytes (GB), and its typical start time ranged from
5-10 minutes. By contrast, Coder's container (code-server) was less
than a GB and offered all of the functionality we would need to
provide an IDE to students, while being both lightweight and fast
with load times under 20 seconds. However, the container is a
significantly more limited version of their enterprise product,
disabling many key features including groups, custom templates,
isolated runners, and high availability.
</p>
<br />
<p>
Given that one of our main goals was to keep costs down, we chose to
use the Coder image as our base since it would allow us to provision
more instances of the workspace container per server than the GitPod
image.
</p>
<br />
<p>
We now had containers that would run on our local machines and were
able to provide individualized workspaces that could be accessed in
the browser. Our next challenge would be running a single container
on a server in the cloud.
</p>
<br />
<h3>5.5 Gaining Access to the Cloud</h3>
<br />
<h4>5.5.1 Starting from Scratch</h4>
<p>
In order to begin building Armada, we needed to make a key
architectural decision: would we focus on a single cloud provider
(<strong>cloud native</strong>) or ensure that Armada works across
all platforms (<strong>cloud agnostic</strong>)? Making this
decision would have real-world implications for the reliability,
scalability, and maintenance cost of our application.
</p>
<br />
<h5>Cloud Native</h5>
<p>
"Cloud Native" is a development philosophy that centers around
building applications with technologies that are "native" to a
specific cloud service provider. One of the most useful features of
a cloud-native approach is that it allows developers to avoid
undifferentiated heavy lifting, meaning that the operational burden
of managing IT services is delegated to the cloud provider. This
allows developers to focus on building the application's core
features. However, by limiting the application to one cloud service
provider, the developers become locked into that provider's
framework, sacrificing the freedom to move their application to a
different cloud provider's platform without substantial rewrites.
</p>
<figure>
<img
src="assets/cloud_native.png"
class="case-study-image"
alt="Three clouds representing several cloud providers includign Azure, Google Cloud, and AWS."
/>
</figure>
<br />
<h5>Cloud Agnostic</h5>
<p>
A cloud-agnostic approach revolves around designing applications
that can be deployed to any cloud environment using open-source
technologies. Building cloud applications in this way gives
developers the ability to avoid vendor lock-in.
</p>
<figure>
<img