Posts written by Sri Rajan
AWS App Mesh is the latest addition to the AWS product potfolio. To quote AWS: "AWS App Mesh makes it easy to monitor and control microservices running on AWS." AWS App Mesh is in public preview as of this post, and we will take a brief look at it.
Why do you need a service mesh
With increased adoption of microservices, some challenges have surfaced for which a mesh is a solution. A microservice architecture consisting of 50 components may help agility with respect to development, rate of change and the overall flexibility, but with it comes a lack of observability which makes troubleshooting harder. The increased complexity with several hundred services talking to each other also makes management harder. A Service mesh helps manage the complexity of these deployments. It helps improve visibility of the connections between services and, in doing so helps with troubleshooting, management, and security. Service mesh uses network proxies to govern the flow of traffic. By placing itself in the path for all connections in your microservices architecture, it can apply control policies & collect metrics. Service meshes also decouples the application logic from the operational logic by adding a layer that is responsible for how the services connect to each other.
One of the benefits of containers is the promise of portability. The Docker® mantra is to build, ship, and run. Containers also promise the ability to, with few changes, move from a developer’s laptop to a production environment and, in the same vein, the ability to move from a data center to the cloud or to many clouds. However, adopting containers alone does not guarantee this. At the core, containers are just a better way of packaging your applications. While they ensure a degree of technical compatibility across many clouds, they don’t ensure complete portability by themselves. In this post, we will look at some of the many considerations from the portability lens.
In this post, we look at Docker, CoreOS & Fleet and demonstrate how one could use all of them in an application scenario.
In the last several years and with the advent of social coding sites like GitHub, there has been an increasing openness in code sharing. This is great on so many levels as it promotes the open source model, and in general is a nice thing.
One security side effect has been the accidental disclosure of sensitive information in the code that is shared publically. This problem existed before with things like database or SMTP passwords in configuration files but in the world of cloud and API keys this problem increases in its severity.
Whereas database servers were generally well protected and so even accidentally revealing the password was not the worst thing to happen, exposing API keys on public repositories has serious consequences. You have given someone the keys to your whole cloud kingdom. With these keys one can spin up servers, view your data, upload illegal data and the list goes on. Hackers are most likely searching on these repositories for such information.
We recently had a good debate in the Rackspace tech community on this topic and this post tries to present some best practices and also some ways to clean up should it happen.
In Cloud Files, there is no built-in way to do aliases or multiple names to the same object. However, after some documentation trolling and speaking to some of our Cloud Files engineers, there is a way to achieve it, although it is not straightforward.
Maintaining hosts files on standard *nix system has been traditionally done by hand. This becomes a challenge as the number of systems grow and this is more true in the Cloud model where you might add/delete servers at a higher rate. One solution would be to use DNS and use a local zone to store your host name to IP mapping. If you are in the automation using Chef world, here is another example on how to automatically generate the host file entries.