OK, let's say I accept your framing ...
What is your proposal or suggestion?
Or are you in a nihilist mood.
511 karma · joined February 19, 2013
What is your proposal or suggestion?
Or are you in a nihilist mood.
ClojureScript is great if you're drawn towards the "production use" side as pixelmonkey said and already have knowledge of the Javascript / Node ecosystem.
Weaveworks is making it easy for teams to operate Kubernetes applications. We provide configuration management and operations tools so that Dev teams can easily deploy apps and Ops teams can manage and operate the infrastructure. Our product helps teams build and run a complete platform - on-premise or in the cloud. If you're interested in DevOps, K8s and operating applications platforms at high scale and complexity then we're a good fit.
* Engineering Manager (North America time-zone) Eng manager helping to build and develop teams that work on our product and key partnerships. https://weaveworks.breezy.hr/p/b7716aa5058601-senior-enginee...
* Software Product Manager (UK / East Coast time-zone) PM role working on engineering to build commercial products for customers that use the GitOps approach. https://weaveworks.breezy.hr/p/cb6e6244349701-software-produ...
* Customer Reliability Engineer (US, UK, EU time-zones) Customer facing engineering and devops role working with customers building and operating their K8s platform. https://weaveworks.breezy.hr/p/92826768709901-technical-serv...
* Front-end engineers (UK/EU timezone) Typescript/Javascript with React and a Golang and Kubernetes backend. https://weaveworks.breezy.hr/p/5afe3735111801-senior-fronten...
* Presales Consultant (UK time-zone) Working with sales teams to explain, promote and design the right K8s application platform for customers. https://weaveworks.breezy.hr/p/69aad97c808d01-pre-sales-solu...
If you're generally interested in the space please watch https://weaveworks.breezy.hr/
Spam was a trademark, it came into common use - it was no longer a trademark.
I have an interest in functional (Lisp) and decided that for me Clojure was a good choice. It was designed to be used in industry so there's people out there who are using it for real applications. Although I wasn't a fan of the JVM I've learnt my bias was wrong and it's given me access to an ecosystem of libraries.
As I'm more informed now I think that learning Racket, F# or one of the others would also have been fine. But, I don't regret Clojure.
They're all small(ish) communities so you have to be willing to invest in the community, be willing to put together solutions from bits of information and enjoy experimenting.
Whether that's the best use of your time is up to you ;-)
The other tactic is that your customers know other companies and contacts in the space. Ask them for help - "as a new consultancy we're trying to build our contacts in healthcare, is there anyone in the industry you think we should speak to?".
> As the company behind a "time limit" licensed codebase, this means I won't get much from the community in terms of code contributions.
It's true that:
> In short, this model may work for companies that want the branding aspect of open source while saying no to code contributions or even community governance models
It probably won't be a "popular model" because there's lots of reasons for creating FOSS - from individual drivers to strategic - so by volume of projects etc. But, for someone trying to create an OSS business "time delayed" licenses are not bad.
More importantly, I wouldn't trust a word that Larry Ellison says - particularly when the primary purpose of the article was to boost the Oracle share price by explaining that Sun would be additive to that quarters profits. I'm not saying that Scott McNeally or Jonathan Schwartz were great execs - I have no idea - but I think you have to look at the goal of the article.
You think you need a COO. What you really need is an operating philosophy.
The point is that lots of teams assign operational discipline to an individual leader or later a team. Irrelevant of the specific methodology ingraining the idea of "create a plan, report on plan" is really important. I don't think that the specific cadence or the nature of the plan matters anywhere near as much as simply having something and measuring yourself against it. That's something the whole team has to take on board - rather than just making it one person's responsibility.
The cadence thing is driven by how much forward view you have, how big the organisation is and how much resource you have available for planning/reporting. The goal is to do "just enough" to drive the business forward - your constantly trying to manage the goldilocks level of chaos (not too much, and not too little). As the business grows and there are more layers and complexity then the length of the planned cycle and the requirements of the cadence will increase.
I understand the point about difference cadence's, personally it's more complexity than I'd like to manage.
Last thing I'd mention is that it's a lot easier to add process than it is to remove it: the negative impact is that it will tend to slow-up the organisation. While adding more process and systems is needed as you grow - the organisation (and certainly the COO/Ops team) should regularly assess whether the whole system fits - process/systems tend to accrete - sometimes that means stopping doing things. The goal is to provide the conditions so the organisation can function well (generally meaning grow) - you need just enough scaffolding to support the organisations goal, as the shape changes you need to remove some bits of scaffolding and support other parts that are under pressure.
If you did an Arts degree (like I did in the UK) you probably recognise this technique. I will admit it was some time back - my degree was all about reading from multiple sources. The goal was to have multiple perspectives on events (in my case history) which are inherently subjective. In reality, there was never enough time - so you "filleted" the core of each argument, grabbed some quotes and dug out some tiny element to "prove" you'd read it. Running 10-15 books - hah - I was researching multiple areas - 15 a week maybe?
And, that's how my degree was made - I'm sure lots of people have similar experiences and skills. I totally accept that this form of reading is possible.
But, beyond "professional learning" it's terrible. It's unenjoyable, develops poor understanding, limits comprehension of nuance and destroys enjoying the flow of the argument. Unless you have to do it, I can't see why you'd put yourself through it. Ultimately reading for learning is not about volume, it's about considered thought.
I mean Debian packaging is a terrible pain - but I have to have empathy with the fact that it's a technical system and more importantly an online community that's been doing it's thing since 1993.
The fact is that with such a long-running system there's more than one way to do everything.
The way we discuss/learn technology has also partly changed. Most of the documentation for Debian is extensive manuals - there's "not enough" intro text, and then "too much" detailed documentation
And then there's the "cost of change". Lots of Debian developers have been packaging using their particular versions of tools for a long time and are happy with them.
In many ways Debian works because the people working on it care about quality and the tooling is second order to the efforts they make.
Anthos is a managed Kubernetes platform: you outsource management of the control plane to Google. If you look at the case studies and the diagrams it's for complex use cases.
Altenatives, might be something like Giant Swarm (https://www.giantswarm.io/), Platform9 or the company I work for Weaveworks (https://www.weave.works/product/enterprise-kubernetes-platfo...)
If you want to run k8s on-premise and have someone support you then Rancher is popular. Most of the specialist consulting teams will provide support: Jetstack, Fairwinds, Controlplane etc
There's lots of options out there - apologies to anyone I missed.
Anthos and OpenShift are trying to create a 'PaaS-lite', or maybe Orchestration++ is a way to think about it.
Alot of the K8s vendors are trying to build a complete experience: for both operators and developers. You can use the CNCF's capabilties (K8s, Prometheus, Istio, etc) to build a container orchestration and developer experience.
(Disclaimer - work in this area). Maybe the difference is that OpenShift is quite tightly bound, whereas Anthos is more modular. The complexity is how all the elements are plugged together and the overall life-cycle.
NOTE: Weaveworks builds application platforms built from CNCF technology so I definitely have 'opinions' in this space
As you said, server users always upgrade. Enterprise desktop users upgrade. A lot of general users don't - they reinstall.
The upgrade process you should use with Ubuntu is different to Debian. In Debian you'd use apt, in Ubuntu you should use the update manager. Update manager specifically checks for upgradability, it has specific warnings and workarounds that are added for each release following testing and reports from end-users. This makes it much easier to upgrade.
The reason why users think the Ubuntu upgrade process is less reliable compared to Debian is they serve different user segments. Most Debian users are technically advanced, engage with the distribution and they often stay in their stream (e.g. testing). Ubuntu is used by lots of normal users - many may not pay particular attention to how packaging works - this means they often do things that make upgrades complex: install community PPA's that advance packages past the next LTS version, install Node into /usr by wiping out apts package knowledge, etc, etc. The range is just bigger.
For many normal users upgrading may no longer be the best option - it's just faster to reinstall. I personally do upgrades, I still find them magical and it's part of the fun: http://www.futurile.net/resources/ubuntu-upgrades/
Also worth looking at is Vlaaad's Cljfx (https://github.com/cljfx/cljfx). And I just want to say the number of examples that Vlaaad has created for the project is amazing and really helpful - it's a great example of helping others on-board to use your project - thanks Vlaad.
1. It's actually cross-platform:
- Still can't use Webex across Linux, Windows and Mac in 2020.
- Same goes for Skype, plus half the users who have Skype don't realise it's Linc and the two are completely different.
2. It's far more bandwidth efficient than things like Slack.
The codecs are much more resilient, this applies (from what I can tell) to all the embedded options that are just using the browser.
3. It's going to be around.
- Google Hangouts has previously been renamed and deprioritised. They also dropped their low-bandwidth codecs and cpu usage went through the roof in my personal experience.
I'm unclear on some of the items against Zoom. But there's a lot of hate and emotion around it in the last 10 days - my sense is that some people have an axe to grind - I'm always cautious of a crowd with pitchforks.
The reality of doing LTS, plus LTS .1 mean that the next standard release didn't get as much attention. So in reality the first six month release was often very rough, with a lot of new things in it that would be straightened out over the course of the entire cycle.
As someone mentions later in the thread Canonical started doing HWE releases, which means you can run a later kernel on the LTS. So I'm running 18.04.4 (I think) which has a HWE kernel that is newer than the one that originally shipped - not just security fixes but newer hardware compatibility.
A bunch of work happens for things like wifi and cpu because of Android and ChromeOS.
But, the number of professional paid developers doing "desktop Linux" drivers is probably fewer than 10 right now [0].
The number of full-time paid developers on "desktop Linux" itself is probably under 100? ... probably more like 50 honestly.
Drivers are of alpha quality (using your definition) because they are not written by the manufacturer. The reliability of drivers is down to the lack of availability of information. The bottom line is that the lack of access to information about how the hardware works means it's hard to make reliable drivers.
Your trackpad example is perfect because AFAIK synaptics had to reverse engineered.
Microsoft doesn't write drivers, the hardware vendors does. And Microsoft runs a test, if the hardware works then it passes the test and gets a sticker on it's butt. HP can only ship hardware that has the sticker. This outsources the cost to the manufacturer and the testing to the OEM.
Whereas, in Linux land those economics don't apply.
I get your points but if you actually want to use desktop Linux then this is one area where you have to go with the grain - buy a PRELOADED certified system because that's going to be built from the smallest set of hardware that the vendor knows is compatible.
[0] meaning there is no-one paid to work on monitors, there is no-one paid to work on that trackpad. What is being paid for is so that Android or ChromeOS can work.
Ultimately, Linux didn't make enough of a dent in the desktop hardware space in the 90's/00's. The level of interest from hardware vendors (ODM/OEM/component manufacturers) has gone down - that's why things are worse.
If you don't use non-preloaded hardware you are NOT signalling to anyone that desktop Linux is important. This reduces overall interest - vendors think that no-one uses Linux - over the long run this reduces the amount of work done.
The take-away is please buy a DELL Sputnik with support - you are signalling to the market you want desktop Linux - and if it breaks you can complain!
I confess I only partially practise what I preach - I'm on a thinkpad =-)
[0] https://certification.ubuntu.com/ and there are other sites [1] https://www.dell.com/support/article/uk/en/ukbsdt1/sln310507...
The basic answer is that operational roles are focused on the current phase of work. Middle level roles are focused on co-ordination. Higher level roles are focused on future phases of work (and managing external stakeholders).
For many of the senior roles the reasons the work is less visible is because it's either in situations employees aren't, or considered confidential. For example, CEO meeting with investors is a big chunk of work, but it's not that visible to employees. For an example of the second, I'd say 'organisational design' and areas of investment are often confidential as they have implications for hiring/firing.
* Blend all our food so that we could extract the maximum nutrients with the minimum amount of chewing
* Only watch movie trailers to get the main plot points without wasting 90 minutes
* Request friends to get to the punch-line of a joke without all the boring wandering around of the story
There are many reasons to read, as there are many reasons to travel. Sometimes it's only about getting to the destination as quickly as possible, and sometimes the journey is part of the experience. The question is whether you as the reader and the writer are on the same journey together, or you're looking for business travel while they are on a slow train enjoying the countryside.
maybe it would be beneficial to replace it or strip it down to ensure your customer never has
to worry about storage performance, for example.
what if your potential customer runs on a PaaS like Heroku
In the end, to offer Prometheus/Cortex as a SaaS and be competitive with existing players
like Datadog, SignalFX, etc I'd expect you'd have to run an API that your customers can code
against to push data to you.
In Weaveworks case we've build integrations into our product that help connect and pull data from other systems. Overall I think Prometheus metrics have a strong future, and there will be lots of SaaS options for sending and consuming the data.
This seems especially important if you want to offer Prometheus as SaaS.
Your customers won't want to run their own Prometheus installs (that's what they pay you for, after all),
and asking customers to open their firewalls so that your Prometheus can discover and scrape their
infrastructure is probably a non-starter.
The upsides of running the agent on their side is that they benefit from Prometheus' automatic service discovery. They can also use standard Prometheus configuration and scrapers to get the full capabilities for their environment.
There are also situations where the user wants to continue to run their own Prometheus, but down sample and send a limited number of metrics for long-term storage in the Weave Cloud SaaS. This can be done with one line in a standard Prometheus.
It's true that running the agent takes resources, I think the benefits are worth it. For most people the key question is getting the full value from their metrics data to enable better development and operations.
[NOTE]: Full Disclosure I work at Weaveworks where we provide Prometheus-as-a-Service (https://www.weave.works/features/prometheus-monitoring/)
Oh and I find it so odd that none of the famous "remote first" bloggers/talkers address these operational issues.
For a small team it's unlikely as the cost of enforcement outweighs the benefit. But as you grow the amounts become more significant and there are plenty of impacts of not doing things properly. Here are way this could impact a business:
* The business won't be able to legally carry out business (e.g. sales) in the jurisdiction because there'll be an outstanding court judgement or tax judgement against you.
* The business' auditors or professional company directors may either (a) ask you to keep money on your balance sheet to account for the outstanding judgement, (b) or refuse to sign-off your accounts.
If you refuse to tell them about the outstanding fines/judgement then you will be taken to have lied to them at which point you may be struck off as a company director. It's extremely difficult to find a professional finance professional to work for a business where ethical and reporting standards are not followed because they will risk being censured and losing their livelihood.
* You won't be able to travel to the jurisdiction (if you are a director/owner of the business) as you'll risk being put in jail/civil fine.
* The state in question can use international tax treatments and bring a court case or enforcement against the company within their main jurisdiction. Unlikely for a small company.
Lets say you have a German company and you have people working across Europe. For the sake of argument lets say that you have 15 people in France. Let say that all the people work for you 100% of the time, so they are effectively employees.
On the employment taxes/benefits front how are you paying the French state those 14 peoples payroll tax, and how are you paying in for their state pension? Pragmatically, you can't do this (AFAIK) without establishing a company in the jurisdiction and registering them as employees.
On the employment rights front, which jurisdictions are you following? As you have 15 people in France they are due to have a workers representative, does that fall under the French or the German system? If you have an issue with one of the team do you follow French or German employment law? Again, pragmatically each jurisdiction assumes that you fall under their employment laws and logically they'll assume you have a company in that geo.
As you note, the other big problem is that it places you in a very uncertain situation with labour law / labour relations.