
Open Application Model Specification - gtirloni
https://github.com/oam-dev/spec/blob/master/README.md
======
twic
> The Enterprise JavaBeans architecture defines six distinct roles in the
> application development and deployment life cycle. Each EJB Role may be
> performed by a different party. The EJB architecture specifies the contracts
> that ensure that the product of each EJB Role is compatible with the product
> of the other EJB architecture Roles. The EJB specification focuses on those
> contracts that are required to support the development and deployment of
> ISV-written enterprise Beans.

\-- Enterprise JavaBeans™ Specification, v1.1, 12/17/1999 [1]

[1] [http://index-
of.es/Java/Enterprise%20JavaBeans%20Specificati...](http://index-
of.es/Java/Enterprise%20JavaBeans%20Specification-1.1.pdf)

------
jacques_chester
Previous discussions:

[https://news.ycombinator.com/item?id=21272082](https://news.ycombinator.com/item?id=21272082)
(focused on OAM)

[https://news.ycombinator.com/item?id=21279366](https://news.ycombinator.com/item?id=21279366)
(focused on OAM + Dapr)

------
cybrexalpha
> When it comes to application development and deployment, we think it is
> important to distinguish between the parts that developers are responsible
> for, and the parts that operations is responsible for. Otherwise, if these
> roles get muddled, it would result in communications mishaps, bugs, or even
> service outages.

Isn't this is the complete opposite of general wisdom these days?

If development and operations are split then you end up with two departments
working against each other. Development are assessed on their ability to
deliver features and operations are assessed on their ability to keep the
service running. So development are incentivised to push for as rapid
deployment as possible, and operations are incentivised to resist deployment
as much as possible (because deployment can lead to downtime).

