search

hamlet-io / engine

Framework for managing cloud infrastructure via templates. It is part of the broader Hamlet devops framework.
GNU General Public License v3.0
5 stars 5 forks source link

Component Names #1378

Open RossMurr4y opened 4 years ago

RossMurr4y commented 4 years ago

Expected Behavior

Hamlet component names in the shared provider should be vendor agnostic and not an acronym requiring insider industry/provider-specific knowledge. They should reflect the way Cloud Engineers already communicate components.

Current Behavior

Many of them are acronyms of the AWS components (AWS being the initial cloud provider implemented) which does not reflect the intended design of Hamlet.

Possible Solution

Vote on primary names for all components, and update those agreed upon with a new name in the names-array. The legacy names will continue to work but we can move forward with documentation using Hamlet-specific component names.

The names below are all the currently implemented shared provider components. To vote on a new name add your comments and we'll discuss.

I have deliberately left out those I've felt sufficiently agnostic (even if it corresponds to an AWS Service - sometimes AWS got it right!) but feel free to add any extras in.

Components

EC2 ECS EFS ES LB S3 SPA SQS

RossMurr4y commented 4 years ago

A lot of scaling services in Amazon use the industry term "elastic". I feel this may not be necessary in Hamlet component definitions - the abstracted component should either be known for it scalability or not.

EC2

"cloudcompute", "virtualisedcompute" ... I feel it needs something to indicate it's not a serverless concept - "compute" alone doesn't reflect this but sounds better.

ECS

"containerservices"

LB, SPA, ES

happy with name, suggest we make the acronym a secondary name and use loadbalancer, singlepageapp, elasticsearch primarily. This will help documentation readability.

SQS

"queue" works for me.

EFS

"filesystem"

S3

"Storage" is already a Reference Type for virtual machine storage. Probably shouldn't overlap them. "stage"?

roleyfoley commented 4 years ago

EC2

"cloudcompute", "virtualisedcompute" ... I feel it needs something to indicate it's not a serverless concept - "compute" alone doesn't reflect this but sounds better.

virutalmachine ?

ECS

"containerservices"

We have talked about splitting out the container orchestrator and the actual services and tasks. If we did that I'd probably go with containerhost and then have top level components for service and task - They probably need different names then

LB, SPA, ES

happy with name, suggest we make the acronym a secondary name and use loadbalancer, singlepageapp, elasticsearch primarily. This will help documentation readability.

We could make the longer names alternates then you could use either and we can document both?

SQS

"queue" works for me.

That works

EFS

"filesystem"

I'd probably suggestfileshare rather than filesystem. System is a lower level file storage and would be closer to ebs in aws and a disk volume in azure

S3

"Storage" is already a Reference Type for virtual machine storage. Probably shouldn't overlap them. "stage"?

Storage is way to broad and stage isn't always the case ( you can have permanent s3 buckets ) objectstore would probably be my preference

RossMurr4y commented 4 years ago

Agreed on all counts there @roleyfoley .