A "Walking Skeleton" is a form of "proof of concept" of your basic architectural concept. Where a proof of concept typically focuses more on a single functionality, a "Walking Skeleton" is a minimalistic end-to-end implementation. A "Walking Skeleton" is not an outline of your concept (only a "skeleton") but is really executable and shippable (it can "walk" :...
The idea is to put all our sensitive data [...]
The meaning of "all" in this sentence should be analyzed very carefully before implementing the solution that you plan.
Ansible vault is a very useful tool, but it should be used only to store secrets that are:
Specifically needed for the ansible deployments
Easily made useless to owners that should become ...
I'm not sure it's a best practice but what I would do is using filebeat to read the log in near real time and push it to ElasticSearch.
AWS provides an ElasticSearch Service which can save you from this part.
The drawback of using filebeat directly to elasticsearch is that the time of events will be the time the prospector read them and if your logs have a ...
We are planning to use ansible vault in our project to prevent leaking passwords or keys in git.
Since you haven't yet implemented anything, you might reconsider this. Using a system like Ansible vault has a number of security downsides:
there is no audit trail of who has accessed it
when an employee leaves, it is easy for them to take the secret store ...
This quite much goes to what internal policies you have on handling sensitive data.
I'd like to tell you my approach to this and explain what I see as pros and cons. I keep the Ansible Vault password in a file on the control machine and have a environment variable pointing to it:
I have that on my ...
Dan is close. I think the easy way to describe the difference is that the two have different customers. The customer of the walking skeleton is the dev (and ops) team, in that it implements the simplest thing from each of the elements of the architecture and strings them together in a working way. For example, it has a front end, it has a backend, it has ...
The walking skeleton reflects the rough structure/shape of the product, but it may be entirely stubbed out (initially), meaning it may not be actually functional. The skeleton cannot move without the muscles.
The MVP however must meet a certain minimum functionality level to be considered viable.
As development progresses the walking skeleton typically ...
start using it if you fail, you can select another technology
This approach has two major drawbacks:
While it may be tempting to apply "fail fast" mentality to architecture and design, skipping or abbreviating the design phase would be a mistake. fast-fail should be used in conjunction with good design practices, not in lieu of them. Making ...
I believe in 'fail fast' but it's also important to tackle understanding an opportunity in the right way.
If you come up with an idea, code in a vacuum for a bit, then release it to people, you will undoubtedly fail fast, but not in a way you would like.
A better approach is if you come up with an idea, clearly articulate your hypotheses on why you think it'...
Based on the following two comments to the referenced answer in the question:
I guess it's the delivery pipeline equivalent of a minimum viable product.
This does sound similar to minimum viable product, but at a more
granular level- "minimum viable component" perhaps. Returning 200 from
a service just to get it "running" ...
Currently my team uses Jira, and it's RapidBoard agile thing. We aren't using real agile, but it's nice to schedule work loads for the next week.
Jira can be super complex, but we Have our tickets set up to:
New -->InProgress -->Done
+-> Won't Do
It can be linked to github or to Bitstream, etc. which is nice. If you want more complex code ...