Last post of the year, maybe it’s a good moment to summarize my progress in my foolish quest to design a modern elastic private infrastructure PAAS for a potential migration of our (Spanish) web services (without jumping straight to an already established platform; that will be the final solution anyway but knowing how it works and with the knowledge of why those processes, which problems existed and how had been tackled).
Goal for new year 2015
No SSH in user space!
No ssh for apps, no ssh for deploying, accessing logs, content, events, monitoring… microservices and containers for the win!
Spanish Web Services/Apps current Status
First of all, even an established PaaS is moot now. The reason is that our apps aren’t cloud friendly, they aren’t elastic, they violate several factors (http://12factor.net/) mainly because they were designed more than 10 years ago and while they have been mavenized in recent years there has been no willingness to redesign them. (I found later that myconnections already mentioned those concepts: Cloud enabling an app and more specifically Re: Cloud enabling an app )
Those factors are:
IV. Backing Services: Dependencies and external services aren’t loosely coupled, they are tightly coupled.
VI. Processes: Except for our ajax web services which are stateless all our webs are statefuls and rely on sticky sessions. Loosing a node (the service in a node) implies the disconnection and loss work for the clients using that node.Apps don’t follow the “share nothing” paradigm.
VII. Port Binding: Our apps aren’t self-contained, they need web servers in front of the jboss app servers for serving static content wich isn’t in the app. It’s a legacy infrastructure design.
VIII. Concurrency: VI Process is a pre-requisite and we don’t comply with it.
IX. Disposability: Migrating from WebSphere to Jboss mitigated a lot the startup/shutdown times but failing VI, easily disposal of services is costly.
XI. Logs: Logs are a mess, there isn’t a signal/noise ratio there is just noise. Some apps log (in info or warn) thousands of lines per second! Each app has it’s own syntax, there are no error codes, no index, nothing, just developer… debug… garbage…
Cloud services are for Cloud
Most of my problems come from the lack of a Lab or a corporate AWS account. A local PC, vagrant and virtualbox aren’t the best tools. Windows, 8Gb of ram, a corporate proxy… it isn’t the best test bed to analyse how the system work.
Lot of names, lot of concepts, managers want a box with a lace, fellow workers look at me like an oddity, maybe they want all done or just no more problems.
Trying to explain the main actors in a cloud infrastructure paradigmI found the following scheme very informative .
There are a lot of more actors but the layer distribution is understandable.
Some technologies are compatible, some are interchangeable. Cloudfoundry and Heroku would be in layer 7 and 4.
Some tools or services like zookeeper, etcd, activemq, redis or databases (both: RDBMS and NoSQL) support or provide functionality to the ecosystem although they don’t have a proper layer.
Most of the technologies seem mature and ready, even Kubernetes which is still in alpha/beta state it’s already a contender. The battlefield is still Docker. Most of my previous concerns are already resolved, the ecosystem takes care of them, but I’m still thinking how to securize it.
The problem is that docker needs an image repository, the docker registry software is available but it’s authentication methods are very limited. They are open by default, anyone with access to the repository (an http port) could not only download an image but also push new ones or worse, replace an existing one.An OPS nightmare. You can’t even “do a git”, the access uses a HTTP Port so no security delegation to the OS. The only choice is using an apache/nginx frontend, the registry accepts BASIC auth but it’s a …
Actually that authentication exists, it’s called Docker Hub and follows a SaaS model. The payment is monthly and I don’t know if there is some type of integration with a corporate IDM, also the authentication is done in remote servers so Internet access is a must too.
Another point of concern is the security/integrity of the containers. The model proposed in CoreOS Rocket seems a lot more robust.
So how the container authorization and security are managed is another point to control when looking at a PaaS solution.